ファイルシステム総合スレ その15

1 ：2012/06/30 〜 最終レス ：2013/02/10

●前スレ ファイルシステム総合スレ その14
http://engawa.2ch.net/test/read.cgi/linux/1326613113/
●関連スレ
ジャーナリングファイルシステム
http://toro.2ch.net/test/read.cgi/unix/979408065/
OpenSolaris/Illumos (OpenIndiana, etc.) 6
http://toro.2ch.net/test/read.cgi/unix/1337411922/
FS関連スレ
http://kohada.2ch.net/test/read.cgi/os/1137387538/l50
過去スレ、関連リンクは >>2-10 あたりで。

2 ：

●過去スレ
01 http://pc.2ch.net/test/read.cgi/linux/1006743807/
02 http://pc5.2ch.net/test/read.cgi/linux/1063025258/
03 http://pc8.2ch.net/test/read.cgi/linux/1101495293/
04 http://pc8.2ch.net/test/read.cgi/linux/1136695633/
05 http://pc8.2ch.net/test/read.cgi/linux/1152348695/
06 http://pc11.2ch.net/test/read.cgi/linux/1164457481/
07 http://pc11.2ch.net/test/read.cgi/linux/1173530292/
08 http://pc11.2ch.net/test/read.cgi/linux/1190788761/
09 http://pc11.2ch.net/test/read.cgi/linux/1225001916/
10 http://pc11.2ch.net/test/read.cgi/linux/1238673446/
11 http://hibari.2ch.net/test/read.cgi/linux/1256639505/
12 http://hibari.2ch.net/test/read.cgi/linux/1256639505/
13 http://engawa.2ch.net/test/read.cgi/linux/1311812102/
14 http://engawa.2ch.net/test/read.cgi/linux/1326613113/
●関連リンク
ext4　　　　　　　 ttp://www.bullopensource.org/ext4/
reiserfs/reiser4　 ttp://www.namesys.com/ (リンク切れ)
xfs　　　　　　　　ttp://oss.sgi.com/projects/xfs/
jfs　　　　　　　　ttp://jfs.sourceforge.net/
nfs　　　　　　　　ttp://nfs.sourceforge.net/
ntfs　　　　　　　 ttp://www.linux-ntfs.org/doku.php
fuse　　　　　　　 ttp://fuse.sourceforge.net/
btrfs　　　　　　　ttp://btrfs.wiki.kernel.org/index.php/Main_Page
NILFS2 (NTT)　　　 ttp://www.nilfs.org/ja/
zfs　　　　　　　　ttp://zfsonlinux.org/
　　　　　　　　　 ttp://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome

3 ：

●関連リンク2
en:List of file systems
ttp://en.wikipedia.org/wiki/List_of_file_systems
Linuxファイルシステム技術解説
ttp://www.atmarkit.co.jp/flinux/index/indexfiles/linuxfsindex.html
Linuxの次世代ファイルシステムは「バターFS」!?
ttp://www.atmarkit.co.jp/news/200807/10/btrfs.html
Linux ジャーナリング・ファイルシステムの徹底調査
ttp://www.ibm.com/developerworks/jp/linux/library/l-journaling-filesystems/?ca=drs-jp
Linux フラッシュ・ファイルシステムの徹底調査
ttp://www.ibm.com/developerworks/jp/linux/library/l-flash-filesystems/?ca=drs-jp
Linux filesystem benchmark 2008/1-2
ttp://www.t2-project.org/zine/1/
ttp://www.t2-project.org/zine/4/
Filesystem Specifications - Links & Whitepapers
ttp://www.forensics.nl/filesystems
Linuxファイルシステムベンチマーク ext3,ext4,JFS,ReiserFS,XFS,NILFS2
ttp://hesonogoma.com/linux/FileSystemBenchmarkResults-01.html
ttp://hesonogoma.com/linux/FileSystemBenchmarkResults-02.html
[Phoronix] Benchmarking ZFS On FreeBSD vs. EXT4 & Btrfs On Linux
ttp://www.phoronix.com/scan.php?page=article&item=zfs_ext4_btrfs
● リンク切れ
File Systems in Linux
ttp://www.linux.org/lessons/advanced/x1254.html

4 ：

● 関連リンク3 （SSD関連）
LinuxサーバーにSSDを使うための情報メモ
ttp://oopsops.hatenablog.com/entry/2012/05/24/164941
Linux+SSDのファイルシステムベンチマーク
ttp://smackerelofopinion.blogspot.jp/2012/06/intel-ssd-520-goodness.html
ttp://hesonogoma.com/SSD/Intel_SSD-330-Series_120GB_Benchmark.html
ttp://hesonogoma.com/SSD/Silicon-Power_SSD-T10-128GB_Benchmark.html

5 ：

いちおつ

6 ：

前スレ1000やめろｗ

7 ：

ハンスははよ出てきてReiser4の次だしてカーネルにマージしろ

8 ：

もう過去の人。今は法律と仮出所条件の勉強に熱心。

9 ：

そういえば「なぜReiser4はカーネルにマージされないのか」みたいな文章あったな。
読んでも結局マージされない理由は良く分からなかったけど
仮に出所してもマージされる日は来ないのかもしれない。

10 ：

>>9
レビューする人がいないから

11 ：

>>1乙

12 ：

>>4
いいまとめだね
付け加えるならfusion-ioにはxfsがいいんだっけ？
どっかにデータ無いかな？

13 ：

engawaがやっと復活したか
よかったよかった

14 ：

各ファイルシステムのディスク上のレイアウトについて解説してるサイトはありますか？

15 ：

ない

16 ：

ubuntuにzfs導入してみようと思ってるんだけど
zfs-fuseとnative-zfsってどこらへんが違うのかな
fuseのほうがユーザーランドで動くから性能悪いのかとは思うけど

17 ：

ubuntuのバージョンが何かわからないけど、
カーネルのバージョンアップが頻繁なデスクトップ版なら、
nativeは止めておいたほうが良いと思う。もし、ユーザのホームを
ZFSに置いたら、カーネルバージョンアップ、再起動、ホームが
見えずにログイン不可、復旧モードで回復という事になりめんどくさい。
オレはCentOSで使っているが、同じカーネルの仮想PCを使って、
nativeのRPMパッケージを作り、動作確認してから本番のカーネルに
あてている。
オレもｆｕｓｅで試して速度に不満があったので、nativeにしたのだが、
fuseの時と、nativeの性能差はあまり感じない。ベンチマークはたしかに
違ったが、動かしているマシンや、CentOS上で動かしているアプリが
大したものじゃ無いので、今となってはどちらでも良かったかなぁと
思っている。

18 ：

>>17
ありがとうございます
OSの種類は12.04のデスクトップ版です
ホームにするつもりはないんだけどカーネルアップのたびに
復旧しないといけないのは面倒臭いな
性能差もそこまで無くて機能差も特に無さそうだし
利便性をとってfuseかな

19 ：

>>18
Native Linux版は64bit OSに入れないといろいろ問題も出るので、
入れるならubuntuの入れ替えも必要な事を使えておくのを忘れてしまった。

20 ：

zfs導入といっても目的がわからないことには。
NAS化したくてシステムはext4に入れるとかならnativeでも不都合はないと思うけど。自分はそうしてる。
あとubuntu+ppaならカーネルアップデートしても自動でビルドしてくれると思うけど。
以前fuseでRAIDZ試したときはあー使えんわこれ、って速度だった印象だけど今ではそうでもないのか？？？
あとnativeはrcといえどstableではないので何があっても知らないよというのはある。
>>19
逆にfuseって32bit版でもパフォーマンス出るの？

21 ：

fuseなんて使うヤツ居るんだとずっと思ってた

22 ：

>>19
ubuntuの32bit版ってそんなに使ってる人いるの?
なんかメリットあるのかね?

23 ：

そりゃあ日本語 Remix版はそもそも64bit版を出してないからな

24 ：

マジかよ
と思って見に行ったらマジだった
i386か…

25 ：

情報の整理はいまいちだけどext4でいいじゃんという結論には同意する
モダンなディス鶏で普通に使う分にはext4でいいよな
Ubuntu 12.04時代のファイルシステムの選び方　ext4でいいじゃん編
http://d.hatena.ne.jp/itiri/20120412/1334238227

26 ：

やっぱext4は最強だわ。

27 ：

最強よりも、他がダメなんだと思う

28 ：

fsckのいらないファイルシステムはよお願い

29 ：

っNTFS

30 ：

nice joke!

31 ：

×要らない　〇出来ない

32 ：

fusion-ioは価格が今の1/2になってbtrfsもサポートしたらバカ売れする予感
btrfsの開発者がボラクルから移籍したらしいし期待していいかな

33 ：

劣化だろw

34 ：

ファイルシステムがなんだろうと
それを読むf系ライブラリに
全ディストリビューションで
バグがある

35 ：

それってLinuxが終わってるってこと？

36 ：

スーパーハカー来タコレ

37 ：

10行ほどの再現プログラムで、お前らでもすぐ書ける
こんな糞バグ、マジかよってレベル

38 ：

>>37
マジで！？
バグ報告よろ

39 ：

>>37
はよ再現コード

40 ：

やっぱり口だけか。
まあ、こんなもんだよね。

41 ：

夏だな…

42 ：

setlocale(LC_ALL, "en_us.utf-8")

43 ：

うそ！？まじで…！？

44 ：

FILE* fp = fopen("test.txt", "w+")

45 ：

error: expected ‘,’ or ‘;’

46 ：

再現コード来ないな

47 ：

XFSが最強だって事は公然の秘密

48 ：

fputws("unko");

49 ：

最強のファイルシステムXFSそしてCXFS
ttp://www.sgi.co.jp/features/2003/nov/media/media_pg2.html

50 ：

東芝REGZAに続いて、ソニー謹製「nasne」のファイルシステムもXFSらしい
Nasne のファイルシステムを見てみる
http://note.ga.vg/blog/2012/07/19/filesystem-of-nasne/

51 ：

だから壊れたの？

52 ：

はやく再現コード出せよ

53 ：

結局、好きなを勝手にの使えって事だろ。

54 ：

太陽のように輝く未来が欲しいのであればXFSを選ぶ事が何より大切な事です

55 ：

それ、btrfsさんの前でも同じ事言えんの？

56 ：

XFSはオープンソースになった当初から使っていたけど、
いろいろなディストリの標準インストーラから外されて悲しい思いをしていた。

57 ：

>>55
btrfsは次世代を担うファイルシステムだと考えております
今はまだ開発が進んでいないので評価する事はできません
「枯れ待ち」という言葉で表現したいと思います
>>56
XFSは必ずやあなたをお救いになる事でしょう

58 ：

xfsサルベージできなくて泣いたからもう手を出したくない
いやそういう運用してるのが悪いんだけど

59 ：

サルベージしやすいFATが最強なんだよ
素人はこういうところを見ようとしないから困る

60 ：

int unko = ftell(fp);

61 ：

if(fseek(0, unko) == -1){

62 ：

perror("err");

63 ：

return;

64 ：

}

65 ：

printf("%d %d"), unko, ftell(fp));

66 ：

fputws("unchi");

67 ：

fclose(fp);

68 ：

ext4のオフラインのデフラグってないの？

69 ：

どこに書いたらいいか分からんからここに書くけど
FreeBSD9.0-RELEAS mem8GB 0EADSx4 RAIDZにIntel SSD330でZILとL2ARCに8GBずつ割り当てた
zpool iostat -vをしばらく眺めてもL2ARCは使われてるけどZILはほとんど使われてない
個人用とで使う分にはZILはあまり役たたんのかな？

70 ：

>>69
当たり前の事だけど使い方次第

71 ：

>>70
うーんそのどういう使い方なら役に立つのかなってことなんだけど
使われてないってことは結局使わなくても書き込み間に合ってるってことだよね
サーバで多数のクライアントからの処理でもないと真価を発揮しないのかなと

72 ：

仮想環境のホストOSのディスクをZFSにして、複数の
ゲストOSが同時にディスクアクセスするというのは？と思い
実際にやってみたけど、あまり効果はなかったね。

73 ：

>>69
同期書き込みしてる？

74 ：

>>73
ありがとうございますZILをちゃんと理解してませんでした
sync=alwaysで常に同期書き込みさせる場合に有効なんですね
つまり非同期書き込み時に高速化させる訳じゃないと

75 ：

O_SYNCとかならわかるけど、sync=alwaysってなに？

76 ：

>>75
zfsのオプションです
sync=diabled：ZILデバイスには書き込まない
sync=standard：O_SYNCのときだけ(ZILデバイスに）同期書き込み
sync=always：常に(ZILデバイスに）同期書き込み
よく分かってないので間違ってるかも知れません

77 ：

ZFSをCentOSのデスクトップ環境で３ヶ月使い続けた結論
ディスクの玉は多いほど読み書きが速くなる
ｰ>ボードの性能がボトルネックになる。
logsは多くても数Mしか使っていない、512MぐらいSSD割り当てれば十分。（か？）
cacheは徐々にallocが増えていくので、時間が経てば効果がでる。（かも？）
容量は多いほうが良い？　24GをSSDに割り当てている。
ー＞目立った効果を感じられない。
圧縮、重複排除機能はOFFの方が安定しているみたい。
ー＞重複排除で20%〜30%の容量節約になるのは魅力だが、書き込みが遅くなる。
メモリー8Gから16Gに増やしたので、そろそろフルで重複排除を働かそうか
と思っている。

78 ：

>>77
FreeBSDのZFSで3TBx5発のraidz2を使ってるが、シーケンシャルでRead 500M/s
Write 420M/s行ったよ。ボードがボトルネックって、単に使ってるボードがPCIex1だった
とかのオチじゃないの?

79 ：

ZILの容量はメモリの1/2で十分らしい
ttp://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide
The maximum size of a log device should be approximately 1/2 the size of physical memory because that is the maximum amount of potential in-play data that can be stored.
For example, if a system has 16 GB of physical memory, consider a maximum log device size of 8 GB.

80 ：

>>78
うん。御名答。
どんなに頑張っても100M/S以上の書き込みができないオンボードのSATA-I/Fなので
がっかりな結果。RAIDカードを買っても結果は同じだろうと思います。もともとは
ホビー用途のボードらしいです。
ただ、書き込みの時にraidz2で30M/Sずつの書き込みで60M/Sの書き込み
読み込みの時に、30M/Sずつの読み込みで90M/Sの性能が出ているのは、
ストライピングの効果が見えて面白い。サーバ向けのボードで使いたいよ。

81 ：

で　用途は？
ただのベンチヲタ？

82 ：

>78
read はともかく write は
dd でシーケンシャルテストしても
数十MB/s とか程度だった気がするんだけど
なにが違うんだろう(FreeBSD 8系で raidz1, 1TBx4発)
お勧めパラメータ設定とかあります?
zpool iostat で見ていると安定して書き込まないで
ちょっと書いては休んでとかしてたのが謎…

83 ：

>>82
休んでるっつーのは ARC に書きに行ってるときじゃね?
つーかパラメータ云々よりどんな構成で使ってるんだ

84 ：

LSIのSAS HBAでZFS使っている人いる？

85 ：

>>82
数十MB/sって…。
raidz1x4の構成なら、仮にHDD 1本あたり34MB/s出ればpool単位では
100MB/s越えちゃうんだよ。むしろどうやればそんな低い性能になるのか、
そっちの方がギモンだ。

86 ：

RAIDZってそんなに書き込み性能出るの？
普通、RAID5/6ってのは単体と比較して
書き込みの回転待ちが倍近くかかるし
chunkサイズx台数に比例したサイズの整数倍以外で書き込み以外は
パーシャルライトになって、強烈に性能が低下するものだと思ってたよ。
実体験上もそうだし。

87 ：

で、書き込み性能低下の要因は
メディアの転送速度でも、インターフェース(のどこか)の転送速度でも
ましてやパリティの計算に使うCPUでもなく
もっと根本的な、回転待ちの同期と、一部書き換えのための事前読み込みに
時間がとられることじゃないかと。
もうひとつ遅くなる原因に思い当たった気がしたんだけど思い出せない。

88 ：

俺の家でパラメータとか何にも考えずに構築した2TB*4のRAID-Zは安定して150MBぐらいは出てるな
ちなみにHP ProLiant MicroServerのFreeBSD。

89 ：

ってことで ttp://ftp-admin.blogspot.jp/2011/11/raid-z.html

90 ：

ちなみにIOPSではなく転送速度ってことなら、シーケンシャルでドカンと
読み込む場合はRAID-Zでも速いです。

91 ：

うちは何も考えずに作った 2TB*8 の RAIDZ2 で 400MB くらいだな
作ったばっかの頃はもうちと出てた気がする
AthlonX4 と 16GB メモリ の FreeBSD 8.2
HBA は M1015(LSI 9220-8i) の IT Firmware

92 ：

>>91
LSI 9220-8iで故障したディスクの特定とかってどうやってます？

93 ：

>>92
いまんとこ mptutil(8) に相当するのが無い
mpsutil が出るのまち。いつになんのかしらんけど

94 ：

>>92
ごめん、何も考えないでリプライしたがどういう意味?
ZFS でってことなら別に zpool status すりゃどのディスクが死んだのか
出るからそれで十分じゃね?

95 ：

いっつも思うんだけどRAID5とかで死んだディスクがあったとして
それがどのデバイスなのかzpool statusで分かったとして
実際にハードディスクの蓋開いて物理的に取り出すときに
全部同じ会社の物だったら分からなくね?型番で判別できるもんなのか?

96 ：

>>95
普通はポートに合わせてHDDを付ける

97 ：

>>95
https://forums.ubuntulinux.jp/viewtopic.php?id=8686

98 ：

>>95
それは >>96 の言うとおりポート順にすればいいし俺はそうしてる
あとバラバラだとしても smartctl とかで S/N は調べられる
見やすい場所にラベルも貼っておいたほうがいいだろうけど

99 ：

>>95
仕組みを考えてみてくれｗ
RAID5は一個ディスクが壊れた時交換することを前提にしてるんだぞ。
そうやって冗長性を構築してるんだ。うまく交換できないなら全てが成り立たない。

100 ：

RAIDを構成する全てのHDDのメーカと型番を変えれば無問題！！

101 ：

HBA側がminiSASで分岐ケーブルなら大概がSATA/SASコネクタに番号が振って
あるから間違いようもないし。
いまはむしろ6GB/sと3GB/sで混在するオンボードの端子の方が勘違い
しやすいんじゃね?

102 ：

タマの物理的な管理もできない奴がRAID組むなよw

103 ：

FreeBSDでzfsのホットスペアって自動でreplaceしないの？
自動でならないんでググって見たら他の人もなってみたいで
自分で監視してdegradeしたらreplaceするようなの作らないとダメかな

104 ：

Solarisだと自動でspare指定のデバイスと置き換えやってくれたけど、
そういえばFreeBSDだとどうなるか試してないな。

105 ：

>>94
エンクロージャーがいっぱいある環境で間違えない保証ってある？

106 ：

保証ときましたか

107 ：

そこは保険をかけてですね

108 ：

保証があるかないかと言われれば、無いですねえ

109 ：

アクセスLEDが消灯してるからだいたい分かる。
ツールでステータスLEDを光らせることができるのもあるけど。
あと手でさわって振動してないやつな。

110 ：

ejectコマンドでcdやdvdを取り出すみたいにHDDも取り出せるような仕組みがあればいいんだけどな。
データセンタとかでは既にそういうのありそうだけど。

111 ：

>>110
物理的にHDDが飛び出すのか。
こえーよw

112 ：

個体差で元気が良すぎるのとかアリそうで嫌だわ

113 ：

飛び出すのは円盤だけだから心配しなくていい

114 ：

UMD射出機能か

115 ：

Win/osx/linux（それぞれ最新のもの）で共通して使うことのできる（読み書き操作できる）外付ハードディスクに適したファイルシステムにはどんなものがありますか？メディアファイル置場としての用途を考えています。
自分の知識ではFAT32くらいしか思いつかないのですが、パフォーマンス的にもディスクの効率的にも見劣りします。
他に選択肢ってありますか？

116 ：

パフォーマンス以前に最大ファイルサイズが4GBなFAT32は問題外

117 ：

2TのHDDをFAT32でデータディスクとして使ってるけど、書籍スキャンデータを保存してるだけなので問題はないが、
１ファイル辺りの上限よりもディスク全体の容量の上限の方が将来的には問題かな。
ジャーナリングが無い分ディスク容量を最大限使えるし、ディスク障害時サルベージツールも充実してる。
今新規にHDDをデータディスクとしてフォーマットするなら、ext3かなぁ･･･。
ext4でもいいんだけ、Ext2Fsdがext4の全部の機能には対応してないから。

118 ：

以外にもUDF

119 ：

FAT64

120 ：

exFAT?

121 ：

ちょいとageますよ

122 ：

ntfsでいいだろ常考

123 ：

まあwindows使う時点でNTFSしかないと思う

124 ：

バターFSでフロッピーディスクをフォーマットしたいです

125 ：

zfsでsamba鯖に最適化するチューニングって何がありますか
zfsのパラメータ調整をググって見るとzfsにあまりメモリを持って行かれないように制限をかけるって言うのが多いんだけど
ファイル鯖なら特に弄らなくてもいいんかな

126 ：

ZFSにsambaか
何故FTPにしないんだろうか

127 ：

>>126
windowsから扱いやすいからですかね

128 ：

今時FTP鯖はLAN内ですら使わない。

129 ：

ext4ってどう読むのですかね。英語圏の人とか。いくすとふぉー？

130 ：

無駄な改行入れちゃったごめんﾃ

131 ：

テヘぺろ

132 ：

てへぺろの苛々感は異常ｗ

133 ：

てへぺろ

134 ：

苛っｗ

135 ：

かわいいは正義

136 ：

サムドライブ並とな

137 ：

どうせテンプレ表現ならてへぺろこつん、まで行かないとイラっとする。

138 ：

Windowsでも2003からシンボリックリンクできたんだけど、smbmountしたら読めなかった
微妙に使いずれー

139 ：

sambaの follow symlinks = yes みたいなオプションはWindowsにはないの?

140 ：

2003でsymlinkなんざ非公式だもの

141 ：

やっぱり次世代型ファイルシステムには、
別ドライブに飛べるハードリンクが必須だとfindを回しながら思った

142 ：

bindでいいじゃん
というかlnとbindの使い分けが分からん

143 ：

bind: root権限が必要。起動時にbind状態にしておくにはfstabに書く必要がある。
　　bindしておけばchrootの中から外にアクセスしたりも可能
ln: root権限必要ないしfstabに書かなくてもいいからほいほい作れる

144 ：

FTPという懐かしい響きに耳を傾ける時がやってきたのだ

145 ：

SSDスレより転載。XFSを使ってるな。
910のベンチ取ったやつがいるな
はえー
Intel SSD 910 800GB のベンチマーク
http://blog.nomadscafe.jp/2012/07/intel-ssd-910-800gb.html

146 ：

XFSへの信頼が私の希望を支えている。
私は信じようと思う。
自らの苦しみを救われたが故に、
同じ苦しみにある人々のために、
働くことを惜しまないXFSがたくさん見いだされるであろう事を。

147 ：

次組むnasはいつ死んでもいいようにRAID5か6でLVM上にXFSにして
一定期間アクセスなけりゃ対象パーティションククリーニングするcron動かしておこう

148 ：

で、中身はエロ動画。

149 ：

USBで繋ぐHDDアダプターで2TB対応していない奴で3TBを認識させる方法ってある？
セクターサイズが4KBなら2TB上限ってことはありえないと思うんだけど。

150 ：

無いと思います。
tp://sunnyone41.blogspot.jp/2012/02/usb-sata3tb-hdd-usb-sata3tb-hddlinux.html
tp://www.century.co.jp/products/pc/hdd-kit/craisu2.html

151 ：

つまりGPTでフォーマットして対応したパーティションツールでも
古いUSB2.0の多くの変換チップは4kb物理セクターに対応していないって
ことか？
物理セクターが4kbならセクター数の上限が2tbと計算されるわけないだからね。
これってUSB2.0の規格で2TBの制限をしている記述を見つけられなかった。
つまりUSB3.0対応の新しい変換チップならUSB1.1/USB2.0動作であっても
2TBより大きなGPTで繋げることはできるって話に思える。

152 ：

読み書きはSCSI由来だもの
Read(10)/Write(10)にしか対応してないブリッヂチップにRead(16)/Write(16)送ったってそれをATAコマンドに変換してくれるわけない
下二行はその通りだよ
ホストチップやケーブルがそのうえでどんなコマンドが流れていようと知ったこっちゃない

153 ：

>>150
＞tp://sunnyone41.blogspot.jp/2012/02/usb-sata3tb-hdd-usb-sata3tb-hddlinux.html
わざわざ貼る価値のある記事に見えないんだが･･･
アフィ目当ての本人？

154 ：

>>153
価値はともかく、そのブログにアフィは見あたらんのだが。
どこに広告があるのよ？

155 ：

>>152
昔2048byte sectorのSCSIのドライブがあったがSCSIで4kに対応していないってこと？
松下製品
USB2.0のSCSIエミュレーションがSCSIの一部はサポートしていなかったってこと？
たしかAdapticのUSB経由のSCSIアダプターで2kセクターのドライブで読み書きは
問題なかったんだけどね。

156 ：

というか現行のHDDは物理4KBセクタでも論理セクタは512Bの製品しかないからあんま関係無いような。

157 ：

>>155
物理/論理セクタサイズなんてお前の問題に関係ねーよハゲ

158 ：

物理セクターが1024バイト同時に論理(OSのIO)も1024バイトもあるぞ。
無知な奴はこの程度の知識もしらないようだけどな。国産機

159 ：

無知だっていいだろ。
その辺をよろしくやってくれるのがLinuxなんだから

160 ：

OSはセクターサイズとか余り関係ない、巨大なサイズでも対応している。
関係あるのは物理層で装置をアクセスするようなTOOLである
フォーマットツールやらFDISKなどの装置に直節アクセスするツールの対応だけです。
BIOSも512バイト以下しか対応していないのがあるのでブートに使う場合は注意
となる。そういう問題じゃないとCD-ROMすら512Byte/Sectorじゃないのでアクセス
出来ないことになってしまうわけです。512byteというのは専用のその手の
ツールを出さないから必要なのであって別に個々に対応すればいいだけのことです。

161 ：

「TOOL」がイラっとくる

162 ：

そんな神経質な奴がむかつく。

163 ：

そんなお前がむかつく。

164 ：

反応しちゃうお前らがむかつく

165 ：

/をxfsからext4に変えたら快適になった
xfsの時はアップデートとかでファイルアクセスが多くなると頻繁にプチフリーズしてたけど
(dmesgでタイムアウトしたのかエラー吐いて死んでた)
ext4はそんなことはなかったぜ

166 ：

>>165
/以外はXFSのままなのか？
OSもハードも何もわからん kwsk

167 ：

どうみても
xfs が barrier=1 (これがデフォ) で ext4 が barrier=0 (これがデフォ) ですありがとうございました、
でしかない。
アップデート(アクセスだけでなく消去が多い)で遅くなるんだから。

168 ：

>>166-167
xfsの/はnobarrier,logfs=8,relatimeでマウントしてた
ext4はdefault,relatime
どちらもubuntu12.04i386で32bit
/以外は/boot以外xfs

169 ：

s/logfs/logbufs/g

170 ：

>>167
デフォじゃねえよハゲ

171 ：

2.6.30以降はrelatimeがdefaultになってるのでは？

172 ：

btrfsの自動修復すげえ
http://green-rabbit.sakura.ne.jp/blog/2012/08/18/3373/

173 ：

ZFSにも自動修復あるんじゃなかったっけか。

174 ：

>>170
ハゲはデフォだろ

175 ：

マジレスすると赤ちゃんにも髪の毛は生えてるんじゃなかったっけ

176 ：

いつのバージョンの話だよ。
髪の成長機能なんてとうの昔に削られとるわ。

177 ：

リファクタリングと言え

178 ：

発毛システム総合スレその１５本目

179 ：

髪×３ファイルシステム

180 ：

すっかり忘れてましたが、ZFS-0.6.0-rc10 公開されてました。
このバージョンからDKMSに対応したみたいです。

181 ：

spl-modules-dkmsとzfs-modules-dkmsをインストールしておくと
カーネルアップに対応して、うまいこと動くみたい。（CentOS 6.3）
zfs-modules-dkmsのインストールの時にspl-modules-dkmsの依存で
怒られるので仕方なく--nodepsオプションでエラーを回避する。

182 ：

ppaから入れてるubuntuでは前から対応してた気が＞dkms

183 ：

>>182
こちらはソースからコンパイルしてrpmパッケージを作ってます。
VirtualBoxで開発環境と試験環境を作り、試験環境で問題が
ないなら、実環境にrpmインストールしてますが、今回の
dkmsはインストール時にエラーが大量に出たり、依存関係で
zfsのdkmsが入らないとか、危険な香りがするので、今回は
見送ることにしました。

184 ：

>>183
結構不安定な感じですね。まぁrcだしそんなもんか。
ちなみにrc10だと# zfs rename -rができないというバグがあった。自動バックアップスクリプト書いてたら気付いたｗ
ubuntu用のdaily build(0.6.0.72)ではもう直ってるのでrc11では直ると思うけど。

185 ：

ttps://twitter.com/kosaki55tea/status/239114285450674176
>>25にkosakiタソが反応している件について、一言おねがいします。

186 ：

ZFSでいいじゃん

187 ：

ZFSアクセラレータチップって出ないかな

188 ：

zfsでいいよな

189 ：

ここに至ってext4推す人ってなんなの？
ZFSを叩き潰したい人なのかな？
それとも単純にアンチLinux派の人とか？

190 ：

>>189
へ？

191 ：

ここはLinux板だぞ

192 ：

zfsって素晴らしすぎるんだけど
メモリー食うしロースペに優しくない
ext3、4が無難
余裕あったらLVMとか

193 ：

raidzなんかはいいなと思うけど
raidなしでzfsをあえてlinuxで使うほどでもない気がする

194 ：

LVMは起動に時間がかかり過ぎる
lvm.confのfilterでsdaしか指定していないはずなんだけど
LVM領域の認識だけで1分以上かかる。
スナップショット機能のためだけにLVM使ってるけど正直辛かったので
この前買ったマシンにはbtrfs入れてやった。

195 ：

エンプラ用途以外でLVMなんかあほ過ぎる
エンプラですら最近じゃ敬遠されてるけど

196 ：

XFSなきUbuntuか、あるいはUbuntuなきXFSか
そのいずれを持つべきかの決断を迫られたならば
私は一瞬のためらいもなく後者を選ぶであろう

197 ：

ロースペに厳しいって、5年まえならまだしも、今やzfsを使いたくなるような
HDDを使う機種で問題になるようなスペックってあまりない気がするけどなあ。

198 ：

luksで暗号化した上にlvmしてその上にxfsでフォーマットしてるは

199 ：

ZFSの暗号化機能はよ

200 ：

チラシの裏
btrfs や zfs の安定を待つのもめんどくさいんで、
ストレージは xfs、あとは全部 ext4 に一本化した。
次の Ubuntu LTS が出るころにでもまた
fs 周りをチェックするとしよう。

201 ：

tune2fsでmetadata checksum有効にした人いますか？

202 ：

バターFSはドッグフードとして食ってるけど、食当たりになったらどうすればいいかな。

203 ：

zfsってZettabyteFileSystemのくせに最大16ExaByteなんだな

204 ：

>>203
fsの仕様と実装との差異かな。ext4も16GBの壁がkernel 3.2.0まであったわけだし。

205 ：

小さ過ぎィ！

206 ：

ZFSはプールの最大容量がZB級じゃなかったっけ？
16EBは1ファイルの最大サイズとかだったような。

207 ：

>>204-203
ワロタ

208 ：

FreeBSDだけどzfs rename -r hogeしたら止まってしまってOSリブートするしかなくなる
-rいれなければ大丈夫なんだけど

209 ：

ファイルシステムのまずさの原因は、ほとんどの場合ファイルシステムにあるのではなく自分の内部にあります。
まず自分の心を点検してみなさい

210 ：

もっとファイル名長問題を盛り上げてもいい頃

211 ：

本体8文字拡張子3文字あれば十分

212 ：

じゃあMS-DOS 2.11で充分かw

213 ：

さすがに拡張子３文字はきびしいです＞＜

214 ：

シェルスクリプトのTempファイルの拡張子、そこを狙って5文字当ててたわw

215 ：

debとかrpmファイル余裕で8文字超えるじゃん
パッケージ名とバージョンとアーテキチャと拡張子で

216 ：

バージョンやアーテキチャをファイル名に折り込むってのも前時代的だよな

217 ：

でも分かりやすくていいよな

218 ：

>>216
今更リソースフォークですか？

219 ：

WinFSです

220 ：

ファイルシステムで管理するんじゃなくて、ファイルに付けないと流通させられないが?

221 ：

>>216
ファイル名って言うのは人間の為につけてるんだよ

222 ：

ファイル名長でReFSに置いてかれるな

223 ：

>>221
rpmの場合ファイル名にアーテキチャ入ってないとエラーになっちゃう

224 ：

あーてきちゃ

225 ：

あーくてきくちゃ

226 ：

>>223
リネームして短くしてもエラーにならんぞ？

227 ：

ここの人たちは、拡張子は必要って思ってるんですか？
今だとウイルスの偽装やら、デメリットの方が大きいと思うんですが。

228 ：

>>227
ファイルシステムと拡張子になんの関係が

229 ：

拡張子ないとファイルの種類を区別できないでしょうが。

230 ：

>>229
マジックナンバー見ればいいだろ

231 ：

Linuxでウイルスの偽装とかなんのことやら

232 ：

・拡張子表示しないファイルマネージャーがない
・「ウイルスの偽装やら」以外のデメリットが提示されていない

233 ：

「(合法)子猫と子犬が仲良くじゃれあう動画.mp4 .sh」とかじゃねーか。

234 ：

pythonスクリプトかcのソースかマジックナンバー見たら分かる訳じゃないしね。
vimやemacsで読み込んだ時のfiletype判定とか大変じゃね?

235 ：

>>229
ファイルシステムはファイルの種類を区別はしないんだが。
ファイル名はただのバイト文字列を格納してるだけ。
拡張子うんぬんは上のレイヤの話。

236 ：

ファイルシステムでファイルの種類を区別しちゃいけないってこともないけどな
拡張子は普通はシェルで取り扱う

237 ：

画像ファイルだって、他人に見せていいものと自分だけで楽しみたいものがあるだろ
そういう区別をファイルシステムが覚えてくれれば、いろいろ便利だと思うんだけど

238 ：

オールドスタイルなパーミッションではダメなのか？

239 ：

フォルダ分けじゃ駄目な理由が特にないけどな。
一応現状でも拡張ファイル属性にいろいろ格納できるんだから
やりたければアプリ側でそこにタグでも何でも格納すればいいんじゃないの？

240 ：

>>233
(合法)子猫と子犬が仲良く... .sh
に省略されるだけで拡張子はわかるだろ。
何か問題が？

241 ：

昔のWIndowsのファイルマネージャーだと空白が長すぎたり改行が含まれてたりすると
最後の.shが表示されなかったんだよ。

242 ：

だから？

243 ：

「(合法)子猫と子犬が仲良くじゃれあう動画.mp4 .exe」
ってファイルを動画だと思ってダブルクリックして
ウィルス感染してた時代もあったってことだよ。

244 ：

いや勿論Linuxだとファイルマネージャーなんか使ってる人少ないから
まずひっかからないだろうし
そもそもroot権限奪わないといけないから大変だろうけど
少くとも>>227の言ってたウィルス偽装ってそういうことだろ。
そもそもファイルシステムの話とは関係ないから俺は降りるかな。

245 ：

Linux板でWindowsの話をしている馬鹿が居る

246 ：

>>234
> pythonスクリプトかcのソースかマジックナンバー見たら分かる訳じゃないしね。
いや、#! /usr/bin/pythonなら、/usr/bin/pythonで実行するから、
上で話題になっているような、想定してない処理プログラムを走らせる攻撃は受けない。

247 ：

Linuxってある程度は拡張子なしで判別できるんだったらやばいじゃん
Winなら拡張子命だから猫.mpeg.exeとかしなあかんけど
Linuxとかなら
中身実行ファイルの猫.mpeg
で自動的に実行ファイルと認識するから拡張子偽装する必要なくなる

248 ：

ダウンロードしただけでは実行できないし、
更にその上最近はSELinuxでダウンロードしたファイルは特別視されてるし。
>>247
Linux使ったことあるの?

249 ：

xフラグ（実行フラグ）が立ってない場合、インタプリタを指定しないとシェルスクリプトは実行されないよなぁ

250 ：

>>215 >>221 を受けて、拡張子は誰も触れないんで聞いてみたんですけど。
拡張子のメリットって何かなあと。
偽装にあまり突っ込まれると困ります。

251 ：

拡張子だってファイル名の一部、ということを忘れてなければ>>221がそのまま答えだと思うが・・・

252 ：

>>240
その考え方はマズイだろ。
ファイルの種類を目視確認するから偽装に騙されるんだよ。
ファイルの種類は取り扱うシェル（と同等のライブラリ）に判別させろよ。
一時期 Windows でセキュリティのために拡張子を表示しろといかいう馬鹿が沢山いたが、
エクスプローラの詳細表示でファイルの種類を表示する方が正解。

253 ：

古臭い人間だが、日常的なファイル変換するのに make 使ってる
コマンドのルールを記述するのに拡張子ないと困る
テキストファイル(org)を PDF 化したり、数値データ(csv)として統計処理したり、ソース(c, cpp)からプログラム作ったり

254 ：

だーかーらー拡張子の話はスレ違いだろうが。
他でやれ。

255 ：

拡張子スレなんてあるの？

256 ：

拡張子スレ自体は10個以上あるな。

257 ：

拡張子はファイル名とは違う「ファイル種別」を示すものとして、
ファイルシステム側で特別扱いすべきものだろ。
現行のファイルシステムがデフォルトで対応できないなら、
少なくとも拡張子をファイル種別として記録できるように
マウントオプションで選択できるようにすべき

258 ：

わざわざ拡張子のために別領域用意して何か嬉しいことあんの？

259 ：

拡張子なんぞ使わなくても拡張領域というものがあるんだからそっち使えや。

260 ：

拡張子よりファイル名長問題の話題しようぜ

261 ：

>>257
拡張子はどうでもよいが、ファイル名とは別にどのような種別のファイルか
記録する方法はあってもいい。
ネイティブなファイルシステムに、その方法がないのはUnixだけだけどな。

262 ：

リソースフォークの復活か。でもあれも別にファイルシステムの機能じゃないな。

263 ：

>>260
あんまり長いファイル名許すと、それに頼った運用する連中が出てきて
その被害に巻き込まれそうだから今のままでいい
>>261
fileコマンドで何が不満なんだ

264 ：

VIVOより美味いのはVIVOだけだけどな

265 ：

>>261
ext系に有る filetype って何のために存在するんだろうな

266 ：

今は拡張子なんかより、大文字小文字を区別するかどうかって問題が大きくなってきているような。

267 ：

大文字小文字区別するかどうかはOS側の問題で
ファイルシステムは大抵区別するはずだけど。
そういやWindowsって今でもNTFSは大文字区別するけど
WindowsのOSは大文字小文字区別しないって仕様なんだろうか。

268 ：

OSかファイルシステムかってのはどういう区別なんだ？
ファイラはOSって区分なんだろうか？
Mac OS Xの場合、カーネルのファイルシステムドライバが、
HFS+ではcase-insensitiveで、UFSやNFSでは、case-sensitive。
ただしFinderが別途case-insensitiveにやってる。
だからCUIだとファイルシステムごとに違う。

269 ：

OS=Opereting System
ファイルシステム=File System

270 ：

obcaseinsensitive

271 ：

MAC のファイル名の濁点問題も健在だっけ

272 ：

tp://key2.jp/~yskhashi/wordpress/?p=427
こんなの見つけちゃったけど、もう作っちゃったzfs poolは作り直すしかないの？
はぁ．．．

273 ：

ファイル名の文字数はwindows並になった？
なってなかったら一年後また来る。

274 ：

>>272
macからnfsで接続なんてことしてなけりゃ関係ないんじゃない。

275 ：

>>272
Netatalkをインストールすれば問題ない。
3.0から設定が簡単になったので、試してみれ。

276 ：

>>263
人間のためのファイル名じゃんw
NTFSでファイル名を長く使えてどんな被害があるの?

277 ：

>>276
ファイルサーバにバックアップしたい時にファイル名で引っかかる

278 ：

ファイル名長いとtarに格納できないんだっけ

279 ：

大文字小文字を同一視するファイルシステムって、ラテン文字やキリル文字やギリシア文字の大小も律儀に同一視してくれるの？

280 ：

>>279
一応こんなテーブル持ってます。
http://opensource.apple.com/source/xnu/xnu-2050.9.2/bsd/hfs/hfscommon/Unicode/UCStringCompareData.h

281 ：

>>277
Linux側でどうにかファイル名ながくできないのか？

282 ：

安易に変えるとLinux内でもバージョン間でファイルのポータビリティなくなるからな。

283 ：

>>281
しょばい話だけどNTFSをLinuxのext3でsamba共有使用とした時に
sambaのファイル名長に引っかかったと思う
sambaで解決してもext3でも引っかかるんじゃないかな
とりあえずサーバ側のディスクをiscsiでwindowsから使ってる

284 ：

>>280
詳しく見てないけどU+1E9Eには未対応だろうね

285 ：

273です。
まだだったか。

286 ：

>>272
その記事は半分嘘。normalizationで指定した正規化方法でファイルを記録してくれるわけじゃなくて、
単にFSにファイル名比較の要求がされたときに設定した正規化を行って比較するだけ。
要はformCと設定してNFDなドラえもんを書いてもNFDで記録されるが、NFCなドラえもんを書こうとしたときに同名ファイルが存在してると返してくれるって動作。
>>275の言うとおりnetatalkに任せておけばそうそう問題は起きないと思う。
ZFS+netatalkで個人的に試した範囲だとcasesensitivity=mixedを忘れた時の方が痛かった気が。

287 ：

https://access.redhat.com/knowledge/docs/ja-JP/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/newfilesys-ext4.html
＞ただし、 リンク数が 65,000 を越えると 1 にリセットされ増加しなくなります。
ってどういう動作なんだろう

288 ：

リンクカウントって>2だから、1だと65000>を意味することにするんでしょ?
struct statのst_nlinkが16bitの互換性とサブディレクトリを65000以上作れることを、
回収できなくなることのデメリットよりも重視するということ。

289 ：

回収できなくなるってどういうこと？

290 ：

サブディレクトリをunlinkしても親ディレクトリのst_nlinkは1(実質∞の意味)のまま。
..の事知らないと何のことかわからないかも。

291 ：

unlinkしても→rmdirしても
# 別スレでUnix V7のこと話していたからw

292 ：

「回収できなくなる」の意味がわからなかった
「回収できなくなる」とはどういうこと？

293 ：

ファイルシステムは、リファレンスカウントのガベージコレクションやってる。

294 ：

もちろん nlink の話題で、デメリットとしての「回収できなくなる」を読めば、恐らくどこからも参照されないディレクトリが残ってしまい消すことができないと言っているんだと予想できる
しかし、コードを読んでも ext4 の rmdir は消したいディレクトリが空なら直接 nlink をゼロにするからnlinkの管理が適当でも正しく動作するし(1)、
実際に65000を越えるサブディレクトリを作ってみてnlinkが1になることを確認してから消しても、容量は元に戻り正しく消せたようだ(2)
そうなると「回収できなくなる」には、僕の理解とは別の意味があるんじゃないかと色々考えて、結果「どういうこと？」と聞くわけだ
にもかかわらず、質問に答えずに .. がどうとか、リファレンスカウントがどうとか別のことを言うのは、よくない
質問には正確に答えるべきだ
もちろん、僕の能力が低いせいで(1)の理解が間違いだったり、(2)が正しい実験ではなかったかもしれない
また、別のバージョンでは挙動が違う可能性は残っている
そもそも、「回収できなくなる」には別の意味があったのかもしれない
そういう色々な可能性が考えられるから、「回収できなくなる」とは何を意図しているのか、正確に知りたかった

295 ：

これは質問が悪いだろ。

296 ：

質問の仕方は悪いが抽象的なことして言ってない回答者も馬鹿

297 ：

んじゃ答えてあげてよ。

298 ：

ディレクトリがハードリンクできる世界からタイムスリップしてきたとか。

299 ：

ちがうだろ、パルスのファルシのルシがパージでコクーンだろ

300 ：

>>298
ln -d

301 ：

>>300
そういうことじゃねえだろ

302 ：

窓から放り投げろ

303 ：

いやそもそも nlink ってのが何なのか……

304 ：

https://lkml.org/lkml/2012/10/3/250
JFSにtrimが

305 ：

jfs使いとしては喜ぶべきことだな。
reiser4が新しいカーネルにマージされるらしいね、こっそり開発続いてたのね。

306 ：

まじかよ
いつのまにこんなページができてたんだ
https://reiser4.wiki.kernel.org/index.php/Main_Page

307 ：

草葉の陰でHansも喜ぶだろうな。

308 ：

死　ん　で　ま　せ　ん

309 ：

>>307
檻の中で
のまちがい

310 ：

>>307
若草の茂み　に見えた。

311 ：

スレ
　どうしてUbuntuは衰退したのか？
　http://engawa.2ch.net/test/read.cgi/linux/1338094841/207-
でやりとりしていて疑問に思ったので教えていただけませんか。
GParted(Ubuntu12.04LTS 日本語Remix LiveCD)なんですが、
200GBのNTFSパーティションを右に100MB移動させるとき、
200GB全てを右に移動させているんじゃないかと思われるほど時間がかかりました。
パーティション先頭100MBにあったファイルを、新しく拡張される後端側の
空き領域に移動させて、それに合わせファイル管理情報を更新するだけで
良いと思うのですが、ダメなのでしょうか?

312 ：

ダメでしょう

313 ：

>>312
そうですか。
例えば300GBのパーティションを200GBに縮小するとき、後端100GBの場所にあった
ファイルは縮小される200GBの範囲内に移動されますよね。
それと同じように、パーティション変更後アクセスできなくなる場所にあるファイルは
変更後でもアクセスできる場所に自由に移動させることができるものだと思っていました。

314 ：

その方法は新しい方の空き領域が足りなかったら破綻しますがな
まるっと移動するほうが確実

315 ：

>>311
NTFSの実装は知らないけれど、
もしも、パーティション先頭からのオフセットで管理している要素があったら・・・

316 ：

普通は相対だろ何言ってんだ

317 ：

そもそも、パーティションの先頭にあるのは管理領域だが。

318 ：

MFTがパーティションの真ん中ぐらいに取られてて60%以上縮小できなかったのはいい思い出

319 ：

MFTを拡大するときにMFTのフラグメンテーションが起きて、
それがパーティションの真ん中に来ることもあるね。

320 ：

MFTは意図的に真ん中にくるようになってるでそ。
デフラグすると意味なくなるけど。
てかNTFSはスレ違いだろ。

321 ：

その理屈だとext234,btrfs以外は板違い…

322 ：

Reiser4「！？」
XFS「！？」
JFS「！？」
XFS「？？」

323 ：

ZFSって書くつもりが間違えたし

324 ：

実際には期待通り１００Mとちょっと動かしてただけでしたとかないですか
調べる気はないが

325 ：

NTFSはLinuxのデフォルトサポートFSだろ

326 ：

えっ

327 ：

Android関係の話で、最近はUSBメモリをNTFSで使うのがデフォらしいと聞いたときはびっくりした。

328 ：

FAT32じゃないんだ。

329 ：

exFATとか言うの無かったっけ？

330 ：

あったよ。

331 ：

ntfsでも大抵の環境は大丈夫なんだろうけど
俺は未だにfat32にしてるな。
ntfsはMacOSやLinuxだといちいちntfs-3gでマウント仕直さないといけないし

332 ：

>>331
俺も、USBメモリとかSD(HC)カードとかだと基本的にFAT32だな。
外付けHDDだとext3/4やNTFSにしたりしてることもあるけど。
PC以外のデバイスで読む可能性が大きい場合はFAT32が鉄板かな、と。

333 ：

>>330
exFATがUSBメモリ用途のFAT32の後継になるもんだとばかり思ってた
MSはそのつもりで作ったんでしょ？
>>331-332
最新情報を把握してないんだけど・・・・
ntfs-3gって今は十分な信頼性あるのかな？
LinuxとWindowsで読めて1ファイル4GB以上OKなファイルシステムでずっと悩んでる
Ext2FsdのExt4サポートって、実用上問題ないレベルに達したのだろうか・・・
もう1年以上アップデートしてないみたいだし・・・
とりあえず今はext3を共用用途で使ってるんだけど、できればNTFSかext4に移行したい

334 ：

UDFの出番

335 ：

>>333
十分な信頼性があるかっていうと、ちょっと分からないけど。
個人的には、内蔵HDDのWindowsとの共用領域はNTFSにしちゃってるな。
マウントしている時にカーネルが刺さったりすると、再起動してもntfs-3gがエラーを吐いてマウントできないことがある。
そうなるとlinux側だけでどうにもならなくなって、Windows側でchkdskが必要になることがある。
本当に稀だけど。

336 ：

>>311です。
皆さんレスありがとうございます。
>>324
8.0GBのNTFSパーティションで試したのですが、
・縮める時は、その分だけのファイルを移動させているようですぐに終わりました
・右、左に移動させるときは、全てのファイル(セクタ(?))が移動されるようです
色々調べたり皆さんの書き込みから、
NTFSの仕様が完全に公開されていなくて、GPartedはMFTのパーティション内オフセット位置を
変更(MFTを移動)する操作が出来ない。だから、確実な「全体移動」をする。
と考えています。

337 ：

遅ればせながらZFS Linux Native RC11が出てましたね。
特に問題なく使えています。
いつになったらRCが取れるんだろ。

338 ：

win共用のusbメモリとか随分前からntfs一択だな

339 ：

でも、USBメモリとかは、暗号化がついたFSじゃないと使えなくない？

340 ：

大切なデータはもちろん暗号化したFS領域にいれてるよ。
全部暗号化しちゃうとデータの受け渡しにすら使えないし。

341 ：

暗号化すると漢字やカタカナのフォルダ名は文字化け起こしてしまうけどな。

342 ：

どこの糞ソフトだよ

343 ：

>>336
NTFSの先頭はMFTって決まってるんだって。
何がどこにあるかは全部MFTに入ってるのに、
MFTの場所が決まってなかったらファイルシステム読めないべさ。

344 ：

単純な全体移動だけじゃなくてBPBの書き換えもやってるという理解だったが最近のは違うの？この手のツール。

345 ：

あとこの手の全体移動するツールって移動中に電源落ちても続きから再開できるような対策とか打ってるもんなん？

346 ：

続きはCMの後

347 ：

>>345
中断しても整合性をキープするのが理想だと思う。
転送前後が重なってるなら、一時的に双方を含むパーティションに拡大して、
デフラグ類似の処理をしながら転送前だけの範囲から追い出して、
その後に転送後の範囲に縮小。
てな面倒な処理をしてくれるといいんだけれど。

348 ：

理想語ってる暇あったら自分で実装すべし

349 ：

他スレでこんなこと言ってる人がいたが、どうよ？？
------------------------------------------------------------------------
NTFSのセキュリティ設定はデフォルトの状態でよくできている
※デフォルトのUNIXのファイルパーミッションは最低といってもいい
　というかそもそも共有という認識がない
　それでも問題点にならないには非常に小規模の共有にしか使わないから
　UNIXでも同等のことができるという意見もあるが「実運用したことのない奴の戯言」である
NTFSのエラー訂正機能はext3より若干上(ext2よりは良くなった)
（割と馬鹿にされるがCHKDSKは神ツールである)

350 ：

>>349
どうよって言われてもな・・・
Windowsユーザーから見れば、まぁそういう言われ方するよねぇ。
ぐらいかと。
Windowsメインの共有なら明らかにLinux+sambaのが分が悪い（当然だけど）
acl周りもしかり。
サーバーとしてWindows用意出来るなら、わざわざLinux+samba使う必要無いしな。

色々反論したいところも有るだろうが、
この書き方してる奴に反論したところで、
徒労に終わるだけじゃね。
ってのが、感想。

351 ：

まぁ、適材適所。

352 ：

>>350
思考が狭すぎ世間をしらなすぎ、お前の言うそれはインストールされた
台数でいえば極狭い世界の知識だ。

353 ：

>>352
では経験豊富なあなたの意見をどうぞ。

354 ：

やめろや。比較は荒れるだけ。
いちいち釣りに付き合うな。

355 ：

デフォルトがどうとかファイルシステムの仕事とは違くね

356 ：

> NTFSのエラー訂正機能
そんなのあるの?
と思って検索したら最近はそういう機能がついた?
http://cloud.watch.impress.co.jp/docs/column/2012lab/20120810_550846.html

357 ：

>>352
そうカッカするなよ。
Linuxとか分からないWinユーザーなんてそんなもんだって。
言いたい事は分かるが、最後にちゃんと感想書いただろ？
関わるだけ無駄だと。
だから落ち着けって。

358 ：

そういう話ならスレ違いでござるな

359 ：

NTFSは不良クラスタが発生すると自壊して被害が拡大するから嫌い
FATの頃は不良クラスタ発生箇所のファイルの問題だけに極限してたのになぁ

360 ：

bad block handlingの無いXFSにも同じこと言えんの

361 ：

>>359
まだWindows2000が現役だった頃その罠にハマったわw
結局その時の常用はFATにした。

362 ：

早くこんな世界が来るといいな
メモリ技術の革新がコンピュータアーキテクチャの変革も導く
http://pc.watch.impress.co.jp/docs/column/kaigai/20121018_566618.html

363 ：

いよいよWinFSの時代か！

364 ：

Wii のバーチャルコンソールとかのゲーム機エミュレータで遊ぶと、
どこでもセーブがありがたいけれど、
不揮発メモリもそんな感じかな？

365 ：

なんとなくサイバーパンクっぽいけどオブジェクトのリンクをたどるのもi-nodeのリンクをたどるのもあんま変わらん気もする

366 ：

HDDがPCからなくなる事はあってもファイルシステムは残る、
ファイルをメモリに再展開しないで直接参照するようになる、
それは現状でも可能。
PRAMが一番単純だ寿命はMRAM、RAMはMRAMになりFLASHはPRAMになる、
速度が稼げればMMは1GBで十分、MMとPRAM間の転送を100GB/sに高める。
スパコンやクラウドは既にメモリ＋演算機構の分散システムになっていて、
大規模な処理ではICｰNWの速度がその性能を規定している。

367 ：

>>349
Windowsのファイル共有がクライアントも含めてセキュアになったのなんてここ10年の話じゃないか。
10年前はサーバですら追加パッケージ入れないとITSECの規準も満たさなかったし。
今もProfessionalじゃないと話にならないだろ？

368 ：

XFSとFTPに出会えた事を誇りに思う
こんな事が言える男が世界にどれだけいるだろう
心から感謝している

369 ：

>>366
その手の話は楽しそうだけど、スレ違いだから遠慮しておく

370 ：

遠慮せず、スレ移動して続けたら?

371 ：

gnomeのごみ箱がntfsに対応していない

372 ：

パーティションに書き込み権限が無いだけ

373 ：

AppleのFusion Drive
SSDとHDDのいいとこ取りのディスクシステム。
Linuxのファイルシステムでまねっこするには、
FlashCacheが一番近いかな。

374 ：

Appleの売り文句を真に受けるとバカを見る

375 ：

Hot Dataという仕組をVFS上に考案されていてまずbtrfsへの実装が進められている。

376 ：

>>375
> Hot Dataという仕組をVFS上に考案されていてまずbtrfsへの実装が進められている。
Hot Data Tracking

377 ：

[Phoronix] EXT4 Data Corruption Bug Hits Stable Linux Kernels
http://www.phoronix.com/scan.php?page=news_item&px=MTIxNDQ
カーネル3.4以降のExt4でファイル破損の不具合ですか。
それとも3.6.2の話かな。
私は2.6.32だけど心配だからExt3で再インストールしようかな…。

378 ：

3.6.2で入ってその後3.4にもバックポートで混入

379 ：

バグの発動条件は短い期間にmount/unmountを繰り返すことみたいだから、
当たることもそうはなさそう。
2.6系だとむしろext4のコードが古すぎて微妙とかないのな。

380 ：

それってautofsとか使ってるとアタる可能性があるってこと？

381 ：

>>376
なるほど、btrfsの今後の実装を刮目して待て！！
という話ですね。

382 ：

抜く前にsyncsyncsyncすれば回避できるかな？

383 ：

>>377
>>379
https://plus.google.com/117091380454742934025/posts/Wcc5tMiCgq7
によると
今のところ調査中みたいだけど、かなり限られた状況じゃないと破損は起きないみたい。
umountせずに電源を切る(umount -l後にbusyが解消される前に切るとか)
次回mount時にnobarrierオプション付きでマウント
この二つを満たした時に破損の可能性が出てくるらしい。
とりあえずnobarrierをつけてない人は、まぁ大丈夫でしょ

384 ：

アンマウント完了前に電源が切られることがある…のか。
そういえば以前から気になっていたけど、Linux終了するとき
外付けのUSB-HDDが「カキューン」とか鳴って
いきなり電源切断されたようになる。
(サスペンド中もUSB-HDDのモーターが回っている)
Windowsなら、HDDのモーターが止まってから静かに電源断されるのだけど。。
(サスペンド中はUSB-HDDのモーターが止まっている)
今回の修正でついでにそこまでやってくれないかな…。

385 ：

>>383
バグかぉ！？
Xが固まって強制リセット後破損
nobarrierつけてるから破損したんだな仕方ない自業自得か
と思って納得してたんだが…？なんか間違ってる？

386 ：

今時のファイルシステムは、不意のシャットダウンでも、破損するんじゃなくて、
新しい書き込みが捨てられるだけであることが期待されてる。

387 ：

それをファイル破損と言うんじゃなくって？

388 ：

元記事の英文が読めないんだねえ。

389 ：

>>387
？

390 ：

書き込みされないのに破損するわけない

391 ：

アプリが書き込んだと思ってるのに、書かれていなかったらファイル破損なんでは？

392 ：

どういうバグなのか理解してから書き込めよ。
「ファイル破損」とかアホかと。

393 ：

データの損失だな。
フラッシュされてないんだからしょうがない。

394 ：

面倒だからいつも電源ボタン長押しでぶち切ってたから心配だお
まあ破損して困るようなデータじゃないからどうでもいいけど

395 ：

ハードディスクの損傷の修復機能はあるだろ？

396 ：

ハンスごめん
EXT4に浮気した俺が間違ってたよ

397 ：

>>393
はあ？

398 ：

よし、仕事終わったしバックアップ取っておくか
$sudo zfs snspshot rpool/export/home@today
楽チン~

399 ：

LinuxのくせにZFSとかずるい

400 ：

思うにXFSとは、もともとあるものとも言えぬし、ないものとも言えない。
それは地上の道のようなものである。
もともと地上には道はない。
歩く人が多くなれば、それが道になるのだ

401 ：

スナップショットはバックアップじゃねぇしｗ

402 ：

バックアップの意味を広く捉えるか狭く捉えるか
オペチョンで消したファイルを復活できるのだって広い意味ではバックアップに違いない
物理障害に耐えられないだけで

403 ：

いやいや、そこは区別しようよ。
バックアップ、スナップショットで意味は明確なんだから。

404 ：

backup の意味は予備とか代役とか非常用とか

405 ：

ファイルシステム的には
$ cp hoge.txt hoge.backup
とほぼ同等のことをCOWでやってる訳だしバックアップって言ってもいいんじゃないの
バックアップが同じHDDあっちゃいけない決まりがある訳じゃないし

406 ：

複製しないし

407 ：

簡単なんだから使い分けましょう。
ベル研のWORMみたいに、光学ディスクにバックアップしながら、
いつでもアクセス可能なスナップショットを作成するのなら、
区別しがたいわけだけど。

408 ：

呼び方は置いとくとしても、
スナップショットじゃハードウェア障害に無力だよね。

409 ：

オリジナルが必須な時点でバックアップじゃ無いじゃん

410 ：

別ディスクへのバックアップだって遠隔地に取ってなけりゃ災害には耐えられない
何に耐えられるかを以ってバックアップかどうかを定めるのはあまり意味が内と思う
コピーやスナップショットやリモートミラーは実現するための技法に過ぎなくて、
非常時に代替として使えるものは何だって広義のバックアップだろうよ

411 ：

pgr

412 ：

>>410
極端な例を挙げても、バカがいっそう引き立つだけだぞ。

413 ：

遠隔地でなきゃバックアップも死ぬよっていうのは別次元の話だな
バックアップの本質的な意義は、明らかに一部または全部が欠損したオリジナルの復元だから
スナップショットも条件限定でのバックアップと言えなくもない
ただ、システムの運用管理を行う上で「バックアップとスナップショットは区別されるべき」っていう話だと思うぞ

414 ：

専門バカ的に、バックアップって言葉の意味を限定しすぎてるだけ
その世界では(狭義には)オリジナルと別の実体を要求されることくらいはわかってる
バックアップという目的に対して適切な手段が場合によってスナップショットだったりディスク内コピーだったりディスク外コピーだったりリモートコピーだったりするだけ

415 ：

名称や定義は重要だぞ
まあお前さんは今まで痛い目を見たことがないラッキーガイなんだろうよ

416 ：

名称や定義に無頓着なのはそっち

417 ：

>>416
いい加減にしろ、ぼけ

418 ：

的外れな『極論』を持ち出した時点でID:uIcmYoX5の負け

419 ：

ゆワイターはあっち

420 ：

同じディスク内のコピーはバックアップではない
その認識が浸透していたならファーストサーバの事件は防げたかもしれない

421 ：

>>420
認識が足りないのはお前だろ…
ファーストサーバでは別ディスクにまるごとコピー（二重化）も取ってあったんだよ。
ところが馬鹿な社員がそっちにもバグ入りOSアップデートしたせいで
コピー側も見事にぶっ壊した。
ホット側とコールド側双方一緒に環境更新とか無能としか言いようが無い。

422 ：

>>421
認識が足りないのはお前だろ…
ファーストサーバは待機系をバックアップと称していたけど、
待機系はあくまで本番系に対する（機能としての）バックアップであって、
データとしての『バックアップ』ではない。
そこがごっちゃになってるから話がおかしくなるんだよ。
データとしてのバックアップじゃないんだから、本番系・待機系ともにパッチ当てるのは当たり前。
じゃなきゃいざって時に待機系が使いものにならず、待機系の意味がない。

423 ：

バカな運用者というのはbyzantine failuresの典型例ですね。

424 ：

この流れ、同じようにバックアップやRAIDについて得意げに解説してくれていたシステム構築発注先のSEが
数日後ノートPCが壊れたとかで、
これまでのメールや資料を再送してくれと泣き疲れた思い出が呼び覚まされた。

425 ：

>>410
ポケコンに打ち込んだベーシックのプログラムを、
紙に写経してバックアップしたのを思い出すわｗ

426 ：

紙にメモするのも立派なバックアップの手段

427 ：

紙にバックアップは最終手段だね。
少なくともPCで取り扱うよりも並べ替えも移動も検索も難しくなるし、
機密情報だったら暗号化もできない。

428 ：

しかもだいたい書き間違うしなｗ
まあそこは、復元するとき柔軟に読み込むから相殺されるけど。

429 ：

ふっかつのじゅもんか

430 ：

最近物忘れが多いからメモするようにしたんだが
自分でも読めないくらい字が下手で困る

431 ：

Ext4のバグがまだあるという…
[Phoronix] There Might Be Another EXT4 Corruption Bug
http://www.phoronix.com/scan.php?page=news_item&px=MTIxOTU
要は64bitのUbuntuにおいて、12.04で作ったExt4に12.10を入れて
12.10のfsckをすると、ファイルシステムが100%クラッシュする
ということかな。

432 ：

暗号化とエラー訂正コードを付けてからメモすれば

433 ：

>>431
ext4がまだ枯れていないという事だろう
安定するためにはもっと人柱が必要なんだ

434 ：

カーネルが
・Ubuntu 12.04 〜 ver 3.2
・Ubuntu 12.10 〜 ver 3.5
なので、似たような状況でも問題が発生するかも知れませんね。

435 ：

まあでも新しいファイルシステムなんてそんなもんだよな。
ZFSも結構問題起きるみたいだし。

436 ：

ext4が枯れていないのにext4でfixされたバグがext3にバックポートされていないものがあるという

437 ：

DebianがExt4を採用しているから大丈夫だと思ったんですが。。
でも今回のはカーネル3.5、先日のは3.4〜3.6。
Debian(wheezy)は3.2だから大丈夫かな。

438 ：

XFSはいいものだよ
多分最高のものだ
いいものは決して滅びない

439 ：

btrfsに駆逐されろ

440 ：

>>438
いいものではなく、商業的に成功したものだけが生き残る

441 ：

Suse Enterprise Server Lnux 11を使ったサーバ構築の案件があって、
試しに仮想PCにインストールしてるんだが、ファイルシステムの
選択にbtrfsが出て来てビックリした。　選ぶと、/パーティションには
使えないらしくインストーラで先に進めないが、データ
パーティションには使えるみたい。

442 ：

grub2ではgrub.cfgでinsmod nilfs2を指定できるようになったので、
nilfs2を普通にrootで使えるようになった。
それにしてもnilfs2のファイル削除の遅さは気になるな。

443 ：

全く関係無いんだけど誰も話す相手がいないから書かせてくれ
随分前から海面上昇が問題になってるけどさ
あれって世界中が貿易が盛んになって
でっかいコンテナ船やらタンカーをたくさん浮かべたからだと思う
北極の氷が溶けたのが原因って言われてるけど
氷って元々ほとんど水のR溶けたら逆に体積減るからあんま関係ないと思うんだよね
どうだろ？
ちなみに俺はXFSが好き

444 ：

長いファイル名サポートはよお願い

445 ：

>>443
ひとり言はこっちで。
http://kohada.2ch.net/yume/

446 ：

海面上昇とXFSに何の関係が？

447 ：

データセンターは山の上に作れってことさ

448 ：

データセンター立てるなら滋賀がいいですよ〜
環境いいし交通の便いいし海抜80m以上あるから海面上昇とは無縁だし

449 ：

寒くないと空冷できないべ
雪でも降れば貯めておいて使えるが

450 ：

滋賀は結構雪降るよ

451 ：

滋賀って例の大津市ある所じゃないか……。

452 ：

何のスレだよ。

453 ：

データをイジメRからやめてください！

454 ：

いじめの名所滋賀県

455 ：

雲散霧消に定評のあるファーストサーバー。
多くのデータが消えていった。

456 ：

常時snapshotのNILFSなら無事だったのにね

457 ：

32bitカーネルと64bitカーネルでファイルシステムの違いが生じるってこと
ありますか？

458 ：

開発者も64ビットと32ビットの両方の環境で動作するのが面倒らしく、
64ビットなら動くけど、32ビットでは動かなかったという事例は
ありそう。ファイルシステムでは無いが、別のシステムで経験があるよ。
開発者にメールしたら「え、32ビットまだ使ってるの？」って。
真面目なヤツで、次の日には改修済みの32ビット版のオプジェクトを
作ってくれたっけ。

459 ：

ま、Linuxであえて32bit使っているのはUbuntuの馬鹿どもぐらい、
というイメージだな。

460 ：

Droid君がアップを始めたようだ

461 ：

>>459
お前も馬鹿だろ。
まだまだ非64bit環境でLinux使ってるの多いんだよ。

462 ：

>>459
おまえのイメージはPCの話だろ
linuxは組み込み用との方が圧倒的に多いだろ

463 ：

>>462
でも組込みも64bit化してかないとヤバイ
2038年問題がヤバイ

464 ：

アホかと。
カーネルの64bit化と2038年問題は関係ない。
time_tはカーネルの64bit化とは関係なく、既に64bit化されてる。
古いファイルシステムの内部データに32bit time_tが残っているのは大問題だが、
カーネルを64bit化すれば直るわけではない。

465 ：

もったいないのが
64bit対応CPUで32bit使うこと
Ubuntuは未だに32bitがrecommendedだし
あと広く普及しているcore2duoは64bit対応だけど32bit全盛期に発売されたから未だ多く32bitCPUとして使われている
64bitにしたら有効メモリーはもちろん処理が速くなる
メモリー4GBも使わないからいいやとかPAEでいいやとか思わずCPUが対応してるならどんどん64bitにすべき

466 ：

適材適所がわからないバカはどうしようもないな

467 ：

拙者32bitのUbuntuを使っている馬鹿でござる

468 ：

左様でございますか

469 ：

ユーザーランド64ビットでもまあ構わないんだけどポインタは4バイトでじゅうぶん。どうコンパイルしたらいい？

470 ：

自分でコンパイルしたコンパイラとライブラリを使ってください。
システムコールはポインタ渡しの部分が32bit版と64bit版と二種類用意されているので、
適切な方を呼び出すようにしてください。
後はELやld.soF内に閉じた話なので好きにやってください。

471 ：

使用目的に合わせて機器・使い方を選ぶのが適材適所であって
64bit対応ハードウェアなら何が何でも64bitで使うべきとほざくのがバカ

472 ：

>>471
だってせっかくのCPUの性能をフルに発揮したいじゃん
「処理速度が向上する」を不必要と思う人はいないじゃん

473 ：

リスト構造をダンプして上位4バイトほとんど同じのみたらメモリーもったいないんだの。
IL64もしくはL64モデルでいい。

474 ：

>>472
キャッシュにおさらまらなくなると遅くなるよ。

475 ：

64bitにしたって、普通の用途では速度向上はほぼ実感できないだろ。
むしろメモリフットプリントが単純に増えるから、メモリが4GB以下なら64bitにするメリットがほとんどない。

476 ：

x32ABIでいいじゃん
つか、FS関係無いだろ

477 ：

x86にたいするx64なら64bitという点ではなくISAの拡張による利点がある
汎用レジスタが増えたり命令相対アドレッシングが可能になったり

478 ：

AMD64はレジスタ周りの設計改善で、64bitで使った方が速いらしい。

479 ：

精度がfloatでじゅうぶんならdoubleより速いのにdoubleの固定観念を捨てられないおじさんみたい。

480 ：

ubuntu64bitだとfluxbox環境でmltermのアイコンがなぜか化けまくる

481 ：

/usr/share/pixmaps/mlterm*を全部表示してみてください。
というかスレ違い。

482 ：

>>479
x86のFPUは倍精度で動いとるからdoubleの方が余計な変換処理入らない分速い
てファイルシステムとどう関係あるんだ？

483 ：

>>482
別にかわらんのじゃないのか。
変換処理なら内部80bitだからdoubleでも入るぞ。

484 ：

SSE

485 ：

>>464
sys_timeシステムコールを見るとtime_t返してるし、libcと同じくカーネル内でもlongで定義されてませんか？

486 ：

>>481
32bitと64bitで差がなかったyo

487 ：

80bitって今日日x87コードなんか誰も書かないと思うけど
現状x87はコードは推奨されてないしコンパイラーもんなコード吐かない

488 ：

>>482
コントロールレジスタを_FPU_DOUBLEに設定していようが変換入るんだがね

489 ：

ext4 の defrag まだかな。

490 ：

e4defragとかfake_defragとか？

491 ：

linuxのデフラグはコピーして戻すのが王道だろw

492 ：

>>489
なんでデフラグしたいの?

493 ：

昔「デフラグする奴は貧乏人」ってスレがあったな

494 ：

デフラグする奴はアホ
初期化する奴のほうが情強

495 ：

本当の情強はLinuxなど使わない

496 ：

freeBSDでZFSを使う

497 ：

SolarisやHaikuもいいな

498 ：

そもそもLinuxが沢山のファイルシステムをサポートしてるのはなぜ？
初期にメインファイルシステムをどれにするかで、迷走したとか？

499 ：

>>498
最初はExt系だけで、Linux気質の「来る者拒まず、去る者追わず」でどんどん増えた様な。。。

500 ：

ext2の実装がひどかったのも、いろいろ作りたい人が出てきた理由だと思う。
ただ最近はきっちりと役割分担が出来ているので、もっとあっても問題ない。

501 ：

煽り要素ゼロで言うんだが、「ext2の実装がひどかった」てすごいな…。
ファイルシステムの実装について評価できるやつがこのスレにはいるのか。

502 ：

十人いれば十人十色の需要があり、それに応えた/自分で開発した
ってだけでしょ。仕様公開してないNTFSのサポートだけが不完全ってだけで。

503 ：

>>501
ジャーナルが無かったので、システムがフリーズしたり、
停電の後、再起動が出来るか不安なファイルシステムだったよ。

504 ：

不安定さはそうだろうけど、
ジャーナリングの有無なんてもんは単に仕様の話じゃね？

505 ：

そのジャーナルのお陰でext3は遅いけどな

506 ：

それはext2の実装じゃなくて設計の話じゃないのか

507 ：

minixのfsがRだったから作ったんじゃなかったっけ？

508 ：

フリーズしたらマジックキー
停電はUPS使うだろ普通

509 ：

>>508
マジックキーって効かないこともあるんですけど
UPSなんて一般家庭にないんですけど

510 ：

一般家庭で使う事が限定の話だったの？

511 ：

一般家庭でなくなったら困るデータとかないし

512 ：

だってLinuxはデータセンター専用OSじゃないもん
データセンターやUPSがある自宅鯖宅でも使われるけど
組み込みやUPSなし自宅サーバー
そして大きいのはデスクトップPC
としても使われる
一般家庭や企業のデスクトップPCにUPSなんてつけませんよ

513 ：

>>511
あるし
家族の写真とか
仕事の書類とか
コードとか
ムフフ動画とか
etc

514 ：

UPSのバッテリが切れて、UPS機能失って単に電源タップとして使って早数年。
劣化したバッテリが溶け出してないか確認するのが怖い。

515 ：

家は貧弱だったのでリホームするまでUPS必須でした。
エアコンのサーモスタットがONするとPCがリブートするんだよなあ...

516 ：

UPSも冗長化しよう

517 ：

電力自由化がほんとに実現しちゃったら家庭でもUPSあった方が良くなるかもね

518 ：

>>500
初代extがクソだったのでext2で再実装されたという話と混ざってないか？

519 ：

多様性だろ〜

520 ：

ext2の時代は対抗馬のfatが恐ろしくクソだったけど
ntfs知ってしまうとアレだよな。ext4もbtrfsも中途半端って幹事

521 ：

ntfsで動いているPCの電源コードを抜くのとext4で動いているPCの電源を
抜きそのまま再度何もせずに立ち上げたときどっちが何もしなくていいかで
評価するべきだよ。
ジャーナルファイルシステムとか言う以前にOSを含めた結果という事実が
重要になる。何もしなくて良いというなら1万回やって1万回同じ結果が
でるかを確認しろ！
#UPSとかsyncしないやつ&処理手順の言い訳。

522 ：

リブート時はsyncを3回ですね判ります

523 ：

昔々、シングルユーザモードでSyncコマンドを実行すると、管理ブロックが
吹き飛んでしまうSUNのSoftware RAIDがあってね。（遠い目）
復旧は出来たけど、徹夜したっけな。

524 ：

人生からXFSを除かば、世界から太陽を除くにひとし。

525 ：

ext3,4の利点は再起動時のfsckが速いだけ。それ以外は全てにおいてext2の方が速い。

526 ：

>>525
ジャーナル切ったベンチマークでext2よりext3が速くなかったっけ

527 ：

そういえばXFSもLinux由来では無いんだよな
SGI IRIXのをパクってきたんだっけか

528 ：

>>527
SGIが移植したんだからパクりとは違う。

529 ：

reiserfsとか

530 ：

>>527
JFSもIBMがAIXのために開発したのがベースだよな。

531 ：

>>526
ext3にはジャーナル切れるモード無いだろ

532 ：

JFSとかXFSとかZFSとか、名前の付け方に芸が無さ過ぎ。
やっぱりvfatがクールだね

533 ：

日本初のファイルシステムがもしできたら
YAKITORI とか FUJISAN とかそういう命名しちゃうんだろうな。

534 ：

NILFSのこと忘れてたorz

535 ：

>>533
KOMADORIとかDOZEUとかの方がいいよね

536 ：

aufsも日本人作だけど、普通のファイルシステムとは趣きが違うかな。

537 ：

aufsは早くカーネルとマージして欲しい。

538 ：

http://gizmodo.com/5959812/
某ファイルシステム作った奴も殺人で転落したが、
セキュリティソフト作った奴も殺しで指名手配される時代になりました

539 ：

社名とか製品名に人名が使われてるとこういうときに怖いよなあ

540 ：

だから空母みたく全部エンタープライズみたいににしときゃよかったのに

541 ：

そうなるとLinuxはこのままの名前だと大きなリスクを抱え込んでることになるのか。

542 ：

Debianは黒歴史

543 ：

Tomoyo Linuxとかな

544 ：

人殺しのRiserは普通に使われてんの？

545 ：

普通に xfs も reiserfs も使ってるよ。
あと xfs 誉め殺ししてるヤツがキモい。
以前執拗に叩いてたのと同一人物だろ。

546 ：

>>545
みんなわかってるよ。
だから無視している。

547 ：

最も軽くて速いのはreiserfs

548 ：

うちのサーバでいちばん使ってるfsはcgroupだわ
# mount | awk '{print $5}' | sort | uniq -c
1 autofs
5 btrfs
9 cgroup
1 cifs
1 configfs
1 debugfs
1 devpts
1 devtmpfs
1 ext4
1 hugetlbfs
1 mqueue
1 nfsd
1 proc
1 rpc_pipefs
1 securityfs
1 sysfs
4 tmpfs

549 ：

ext4でなくbtrfs 使うメリットって何？
やっぱスナップショット？

550 ：

ramfs最強

551 ：

>>549
subvolumeが作れるとかsoftware RAIDがあるとか

552 ：

>>549
ラリー・エリソンにケツの穴までどころか身も心捧げられる

553 ：

ZFSっていつ主流になんお

554 ：

>>548
なんでバラバラで使うの？

555 ：

>>548
何で29もマウントされてるの？
普通10もないでしょ

556 ：

>>552
メインの開発者がもう逃亡してるから滑ってるよ

557 ：

>>555
俺は26個だった
最近はcgroup関係とかusbfsとかそういうファイルシシステムじゃない
カーネルモジュールによってmountされてるものが多いな

558 ：

>>557
フォーマット（区画がない）しないのにmountされることはないだろ。
カーネルに実装されていればmountされているというなら誰でもmountされて
いるというべき。

559 ：

犬がマウントしてる

560 ：

>>558
devfs

561 ：

>>558
意味不明
nfsは？

562 ：

mountされている一覧にでてこないものをmountというのって頭変じゃね？
最低でもマウントポイントのディレクトリ作ってから家よ。

563 ：

>>530
しかしLinuxのJFSはOS/2実装がベースなのだった。
最初のうちは「大文字小文字の区別ができない」とかそんな制限があったような。

564 ：

>>562
mount(2)システムコールを呼ぶ際に/etc/mtabに書き込むかどうかは
アプリに依るんだしそれは言い過ぎじゃね?

565 ：

ここはmountについて語るスレではなくファイルシステムについて語るスレだ。
local,network,pseudoとくに限定してなさそう

566 ：

[Phoronix] Linux 3.7 File-System Benchmarks: EXT4, Btrfs, XFS
ttp://www.phoronix.com/scan.php?page=article&item=linux_37_fsthree

567 ：

>>530>>563
いやもともとOS/2でdevelopされて、その後LinuxとAIX。
OS/2以外ではcase insensitiveはoption。

568 ：

JFSならAIXがオリジナルだろう
HPFSならOS/2だが
　　

569 ：

JFS1がAIX上。1990
大幅に改定されたのがOS/2上。これがLinuxとAIXに移植。1999
移植と並行してAIXが主開発場になって、1997
JFS2へ。2001

570 ：

ZFSで冗長性なしでストレージプールを作成した場合
HDDが一台でも物理故障したらプール全体が死ぬという理解であってますか？

571 ：

>>570
合ってます。
一ファイルが複数台に分割されて書き込まれるので…

572 ：

2040年問題 - HFSのタイムスタンプは2040年2月6日までしか取り扱えない。
2048年問題 - 2038年問題の1980年起点版。FATファイルシステムのタイムスタンプなどが1980年起点である。
2079年問題 - FATファイルシステムのタイムスタンプの起点の1980年1月1日を基点として、年数を下2桁だけで処理するソフトウェアなどは、その起点の99年後（2079年12月31日）までしか正常動作しない。
2108年問題 - FATファイルシステムのタイムスタンプは2107年12月31日までしか取り扱えない。
-----------------------------------------------------------------------
60056年問題 - NTFSのタイムスタンプは60056年5月28日までしか取り扱えない。

NTFSはいいとしてFATとかどうすんお

573 ：

FATの2048年とか2079年問題はファイルシステムの問題じゃないよね。
2108年問題はファイルシステムの問題かもしれないけど、あと90年もFATが現役かなあ？
2040年のHFSの問題はファイルシステムの問題かもしれんけど、古いMacなんか趣味でしか使われてないから問題なさそう。

574 ：

OSやAPがFSのタイムスタンプを符号あり扱いするように仕様変えれば
FSのブロックレイアウトは変わらないから68年先伸ばしできるお？
作りかえれないOSやAPはコードよりデータの寿命を優先してそれまでに捨てる

575 ：

そんなのもはやFATとよべない。
おれの誕生日に作ったファイルかはるか未来のファイルに化ける。

576 ：

2048年問題って聞いたことない
FATの精度が2秒だからそんなのないんじゃないの？

577 ：

>>576
FATディスクフォーマットのタイムスタンプが累計秒数で記録されていると思ってないか

578 ：

ttp://free.pjc.co.jp/fat/mem/fatfile2.html
FATは年(7)/月(4)/日(5) 時(5):分(6):秒(5)と
カッコの数だけビットを割り当てて管理してるので
2048年に何か問題が起こるとは思えない
7bit確保されてるので1980+127=2107年まで大丈夫
でもDOSが内部的にどう時間を管理してるのかよく知らない
2048年に何か起こるんですか？

579 ：

>>578
ファイルシステム上は問題は起きないが、ファイルのタイムスタンプを1980年1月1日深夜0時ジャストからの経過秒数として32bit整数で保持しているプログラムが正常に動作しなくなる。
……ただし、そんなプログラムが実在するかは知らない。

580 ：

DOSの時間系関数を使って管理してるDOSアプリには2048年問題は起こらない
ダメなのはC標準関数使ってるDOSアプリということですね
UNIXからFATをフォーマットしてる場合は48年以前に38年問題にひっかかるわけですし

581 ：

×フォーマット
○マウント

582 ：

いや、やっぱりC標準関数は1970年を基点とするからそれはないだろうな
FATで0x0000 0x0000というタイムスタンプのファイルがあったとして
それはエポック秒で315500400と変換されてしまうから48年問題は起こりそうにない
アプリで独自に符号付32bit値として保有してる場合だけに48年問題は起こる
こんなアプリ作ってる人いるんかいな？

583 ：

Linuxのmanpage見たら、ファイルの状態を取得する stat(), fstat(), lstat() 関数は、
ファイルの日時に time_t を使っていますね。
time()関数 〜 紀元 (1970年1月1日00:00:00 UTC) からの経過時間を秒単位で返す。
も、返すのは time_t。
time_t をたどると正体は
　/usr/include/bits/types.h:103:#define __SLONGWORD_TYPElong int
で 32bitのようですが、time_t を使うもの全般が、ファイルシステムに関係なくまずいのかな。

584 ：

>>583
くっついてるw
× > 　/usr/include/bits/types.h:103:#define __SLONGWORD_TYPElong int
○ > 　/usr/include/bits/types.h:103:#define __SLONGWORD_TYPE long int

585 ：

time_tの正体が何かはシステムによって違うでしょ。

586 ：

>>464
＞time_tはカーネルの64bit化とは関係なく、既に64bit化されてる。
まじで？
time_tが64bit化されたlibcのバージョン教えてくださいおねがいします

587 ：

GNU libcではtime_tはlong intであってlong intの大きさは処理系定義なので
まあきっとあってもおかしくはないとかなんとかかんとか

588 ：

32ビットでフォーマットされているものを突然64ビットで扱おうとして
データを壊しまくるファイルシステムｗ

589 ：

>>586
＞>>464
＞＞time_tはカーネルの64bit化とは関係なく、既に64bit化されてる。

ubuntu 12 i386でsizeof time_tをprintしてけど32bitだ

590 ：

Ubuntuは32bitということですが
64bitに対応したLinuxディストリビューションはどれになりますか？

591 ：

あと初歩的な質問になりますが
32bitのLinuxからも、64bitのLinuxからも、
同一のファイルシステムをmountして問題なく扱えますよね？
例えば、ファイルのタイムスタンプの扱いが気になるのですが、
そこは、どちらにしてもファイルシステムの仕様通りに
きちんと処理してくれているということでしょうか。

592 ：

Ubuntuにも64bitなかったっけ
マウントの問題は大丈夫

593 ：

__STD_TYPE __TIME_T_TYPE __time_t; /* Seconds since the Epoch. */

594 ：

>>592
Ubuntuに64bitありますね
ありがとうございます

595 ：

#include <time.h>
#include <stdio.h>
int main(void)
{
　printf("%d\n", sizeof(time_t));
}
8だった@Debian sid/amd64

596 ：

ちょww8ビットてww

597 ：

8bytes

598 ：

>>595のやつ
Debian6.0.6@amd64(サーバー)
Ubuntu12.10@amd64(デスクトップ)
どっちも8でした

599 ：

>>591
x86とAMD64で何が違うのかをもうちょっと知れば、そういう質問は出てこない気がするなあ。

600 ：

Linux vmware-virtual-machine 3.2.0-33-generic #52-Ubuntu SMP Thu Oct 18 16:19:45 UTC 2012 i686 i686 i386 GNU/Linux
Linux version 3.1.10-g22b4fcd (android-build@vpbs1.mtv.corp.google.com) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #1 SMP PREEMPT Fri Nov 2 10:55:26 PDT 2012
てもとだとこの2つはsizeof(time_t)は4だったが
>>464の
「time_tはカーネルの64bit化とは関係なく、既に64bit化されてる。 」
と矛盾してないのか？

601 ：

>>599
32bitと64bitとしか書いてないからx86とamd64とは限らない。
というかその二つに限定すると理解が疑われかねんな。

602 ：

なんとなく気になったので同じ環境で-m32つけたら4になった
ちうことで2038年までに64bit環境に移行すれという事らしい

603 ：

>>601
「初心的質問」でそれ以外のアーキテクチャを
持ち出すだろうか？

604 ：

つかどう考えても>>591が言ってるのはamd64とi386のことだろ。

605 ：

ttp://toro.2ch.net/test/read.cgi/tech/1351769173/620
スレ立てるまでもない質問はここで 122匹目で話題になってたけど、
アップデートしない組み込みLinuxはヤバそうだね。

606 ：

単純な64bit化だと上4バイトは100年ぐらい使われないから
その領域を有効活用しようという輩がいるかもしれない

607 ：

>>606
COBOL世代とはビット単価が違うからなぁ

608 ：

アップデートしない組込環境ではtime_tうんぬん以前に脆弱性がやばい

609 ：

組み込みってネット繋がないじゃん

610 ：

んなわけあるか

611 ：

ext3では秒単位で2038年まで

612 ：

ZFSの重複排除、当たり前だがメモリすげぇ食うな・・・
ファイル鯖としちゃあ便利な機能だがそんなにコストかけれないし重複排除は諦めるか

613 ：

メモリだけなら今安いから大したコストじゃないけど
CPUもそれなりのがいるんだろ？

614 ：

>>612
なんで当たり前なん？
メモリーがたくさんいるのはなんで？

615 ：

ファイル鯖にそんなCPU盛りたくないしねぇ。
ついでに他のアプリケーション動かせばいいんだろうが、なんにせよ個人じゃそんな鯖にゴリゴリさせる仕事がない。
重複排除とか圧縮かけても軽いくらいスペック盛るくらいなら、その金でHDD増設した方がいいんだよなｗ

616 ：

重複排除ってどのくらいのスペックあれば快適に使えるの？

617 ：

>>616
ZFSのrecordsizeによるけど、デフォだった場合、
データ1T辺り、重複排除だけで10G+ってオーダーでメモリーが必要になったはず。
L2ARCにSSDを用意しないと、メモリーから溢れた瞬間、とてつもなく遅くなる。
CPUよりメモリーの方を何とかしないとダメ。

618 ：

>>612
l2arcの出番じゃね？

619 ：

同一内容を検索・識別するんじゃなくて、
ファイルコピー動作とかを認識して重複排除するとかできないんだろうか？
最近読みだしたデータに限って同一判定するとか。

620 ：

>>619
よく意味が分からんけど
書き込みが発生したときにブロック単位で同じのがあるかどうかを見るんじゃないの
そのテーブルがメモリをバカ食いするってことだと思うけど

621 ：

それただのCoWじゃねーか？
NAS上で完結する世界ならそれでもいいけど、実際に求められてるものとは違う

622 ：

重複判定できるってことは、そのぶん余計なメタデータを読み書きしないといけないんだから性能落ちるよね

623 ：

重複排除によって無くなった行われるはずだったユーザーデータの書き込み量のほうが多いかもしれない

624 ：

>>623
クラウド、VPSの仮想HDDの中の/bin以下のファイルみたいなかなり特殊な用途？

625 ：

XFSを褒め殺しにしていると疑われているオレ様がやってきましたよ
褒め殺しではない
純粋に褒めているし実際に使っている
叩いた事など神に誓ってない
ZFSなら叩きたい

626 ：

そっか　よかったね

627 ：

XFSとZFSの良いとこ取りの新ファイルシステム YFS

628 ：

>>619
特定の状況だけ適用してもらいたいんならその状況時にユーザーモード側でioctl発行しろと返されんのがオチ

629 ：

>>618
HDD増やした方がコスパよくね？業務に使うならともかく個人ならな

630 ：

同じ形式のファイルをテラ単位で扱うような用途じゃないとあまり恩恵はないだろうな
少なくても自分は容量食ってるのは動画とか音楽とか写真だから全く意味無い

631 ：

仮想マシンのファイルはほとんど同じなので、
重複排除でバンザーイと思って、Virutalboxと
ZFSの組み合わせを試してみた事がある。
ほとんど重複排除の効果は無く、一時停止で保存した
ファイルでゲストOSが再開できないとか、逆の意味で
バンザーイの結果だった。

632 ：

世代バックアップとか

633 ：

ハードリンクで済むような

634 ：

大きいファイルの世代バックアップには有効そうなんじゃない?
何ギガもあるsqliteファイルとか。

635 ：

バックアップになってるのかそれ
前にもそんな議論があったような

636 ：

まあ核攻撃に耐えられなければバックアップとは言えないからなあ
バックアップでないものをバックアップと言う人が多いよ
まったく

637 ：

前の議論もそうだけど
勝手にバックアップのハードル上げてるだけだと思うが

638 ：

月面データセンターだと万全のバックアップできる
応答時間に数秒要するからバックアップにしか使えないけど

639 ：

月は出ているか？
ってガンダムXごっこができるな。
スペースデブリの月面DCへの影響は無視してもいいよね。

640 ：

電磁波って宇宙だと減衰しないから
宇宙に向けて全データを電磁波の形で発信しておけば
少なくともこの宇宙がなくなるまでは保存されるな。

641 ：

>>640
その発信したデータを読みたければ、電磁波より速く飛んで先回りして受信しなければならないのでは

642 ：

え？ｗ突っ込むとこそこかよｗｗ
文系かよｗ

643 ：

ZFSの重複排除ってメモリに蓄えるから、
不意の電源OFFだと全部破壊されちゃうんだよね
それだとバックアップに使うのは怖いな

644 ：

んなわけない

645 ：

>>643みたいな幼稚な人が作ってるファイルシステムあったら教えて下さい。

646 ：

>>640
波長によって激しく減衰する、宇宙は完全な真空ではなく万年やら億年
経過したそれが何も影響しないというのはアフォ。

647 ：

>>645
ZFS

648 ：

ファイルシステムとバックアップは分けて考えなければいけない

649 ：

分けて考えないのが近年の高機能ファイルシステムでしょ！

650 ：

>>649
って誰が言ってるの？

651 ：

俺だよ。この俺が言ってんだし間違いない。

652 ：

この前、自分定義のバックアップって言葉使って馬鹿にされた馬鹿が
粘着してるなぁ。

653 ：

>>651
ソースは2ch (笑)

654 ：

その時馬鹿にした連中の方が勝手な定義してたな

655 ：

しつこいよ

656 ：

>>654
お前、本当に馬鹿なんだな…

657 ：

定義なんて話の都度擦り合わせればいいのよ。

658 ：

はいはいビールジョッキ思想

659 ：

zfs-win - ZFS for Windows
http://code.google.com/p/zfs-win/
あるにはあるんやな

660 ：

ZFSのファイルシステムにMysqlのデータを置いた環境があり、
某システムの評価で圧縮して400MバイトのMysqlのダンプファイルを
インポートしてみた。
平時はあまり使われない、Logsの領域にも激しく書き込みがあり、
Logsのallocの領域がみるみる増えて行く。raidz1のディスクで30MB/sec
Logsの30MB/secと合計で60MB/secの書き込みが出来て、ZFSの
実力の一部が判った。

661 ：

XFSが3.7でinode64がデフォルトになるから3.6以前に持ってく時は気を付けろー
http://kernelnewbies.org/Linux_3.7

662 ：

なんでext4には作成日時のタイムスタンプがないの？

663 ：

>>662
いや、あるよ。

664 ：

ctime無いのはFAT位でないかい

665 ：

ctimeってリンク数増やしたりとかしたら変わらないかい

666 ：

それはmtime

667 ：

ZFS Linux Native RC13が出てました。
いろいろ直っているみたいだが、ウチの
自宅サーバでは何の問題無く動いているので、
違いが判らん。

668 ：

ctimeとcrtimeは混同してはいけない

669 ：

birth time があるよ

670 ：

>>666
誤り
mtimeが変わるのはファイルの内容を書き換えた時
リンクカウントの増減はメタデータだけの変更に当たる

671 ：

ctime をファイル作成日時だと勘違いしてるやつがいるのか?

672 ：

NTFS ボリューム上で新規ファイルが作成できない現象について
http://blogs.technet.com/b/askcorejp/archive/2010/04/26/ntfs.aspx
$Secure のデータは少しずつ登録される事が多く、非常にフラグメントが発生しやすい環境です。
$Secure のフラグメントが解消される事で、登録できるセキュリティ記述子の数が増える事が期待できます。
Windows7 / Windows Server 2008 R2 以降の環境で発生した場合には、まずはデフラグの実施をご検討ください。
※ 現在、Windows 7 / Windows Server 2008 R2 環境でデフラグを実施したところ、反対に $Secure の File Record 数が増えてしまったという報告を受けています。
詳細が確認出来次第この記事をアップデートいたしますので、それまで $Secure の ATTRIBUTE_LIST を減らす事を目的としたデフラグの実施はお待ちください。

;(；ﾞﾟ'ωﾟ');

673 ：

raidz や raidz2 で、玉を増やすほうの grow が出来るようにならないかなあ。

674 ：

>>672
その地雷を最初に踏んだ人がどれだけ悩んだか
話を聞いてみたい

675 ：

重複排除と透過圧縮とファイルのチェックサムの機能がある
ファイルシステムってZFSだけでしょうか?
調べてみるとlessfsは重複排除と圧縮機能があるみたいですがチェックサムはなさそうで
ext4とbtrfsは圧縮とチェックサムがあって重複排除はない(btrfsは実装予定?)みたいです

676 ：

>>675
http://en.wikipedia.org/wiki/Comparison_of_file_systems

677 ：

ext4のチェックサムってメタデータだけでしょ

678 ：

データが化けてもメタデータさえOKならファイルシステムの整合性は完璧だからな。

679 ：

ファイルが壊れてもファイルシステムが壊れなければ意味があるっ

680 ：

raid5+xfsでデータ化けするて聞いたんだけど
raid5で1ディスクの1ブロックだけ化けた場合でも修復できないんだっけ？

681 ：

釣りか？ ソフトウェアRAID だろうが、ハードウェアRAID だろうが、RAID5 と
ファイルシステムではレイヤーが違うから「RAID5+xfsでデータ化ける」なんてことはない。
データが化けるのは別の原因で xfs 以外のファイルシステムにしたときに、たまたまその
ブロックを踏まなかったってだけだろ。
この場合ハードウェアRAID が何らかの故障を抱えているんだと思う。
ただ、アクセス速度を上げるために、パリティチェックしない製品／設定がある
(ハードディスクに全くアクセスできない場合のみパリティから修復)らしいので、
「raid5で１ディスクの１ブロックだけ化けた場合でも修復できない」事はありえるが。

682 ：

ディスク3台で A,B,パリティ になってる所で
パリティ部分がデータ化けしたらそのブロックは修復できんの？

683 ：

RAID5ではどっちみち化けたら修復できない。どっちが正しいか判別できないからだ。
RAID-Zなら別だがな。

684 ：

なるほどね、勉強になった

685 ：

1ビットのパリティは1ビット以内の誤りを検出できるだけだからな。
化けられたらどうしようもない。
運を天に任せて1台切り離せば読めるかもしれないぞ。

686 ：

エラーにならずにデータ化けってありうるの？
HDDにCRCが付いてるだろ。

687 ：

何もせずとも、いつの間にかデータが書き換わってしまうことはありうる。
そのため最近の RAID 装置は、「書き直し」ジョブが定期的に走るようになってる。

688 ：

HDDは10^-13から10^-16。RAMは10^-10から10^-17。NWは10^-12。
なので1[PB]とか読み出したら、上位（RAMならECCとか）でチェックしない限り確実に誤データが入り込むんでない？

689 ：

>>683
btrfsのRAID5も、実装されたら修復できるようになるんじゃないかな。
出る出るといわれ続けてもうすぐ4年経つんだっけかw
btrfsではデータブロックのチェックサム(CRC)を記録してるから、
化けたブロックは特定できるはず。
どのデバイス上のブロックが化けているかが分かれば、
残りのデバイス上のブロックからXORでブロックの中身を計算して
書き戻せば修復できるはず。
もっとも、RAID5以前に「読み」「書き」以外のことをすると
高頻度であっさりハングする不安定さをどうにかすべきだと思うが。

690 ：

brtfs捨てて、ZFSのライセンスを見直すだけでいいんだけどなぁ

691 ：

ZFSはクローズドソースになっちゃったんじゃないの? FreeBSDは、オープンソースの最終版からフォークしたような…

692 ：

Linuxファイルシステムの進化ももZFSがクローズドでは、もう期待出来ないね。
真剣にNTFSライセンスの購入を検討した方がいいんじゃないの？

693 ：

>>692
ZFSはlinux界隈じゃなくてUNIX界隈だから関係ないよ。

694 ：

クローズドからオープンになった事例は結構ある。
ってかオラクルは何でクローズドにしたんだろ。

695 ：

>>694
ライバルを買収して相手製品を死蔵して潰す場合と、
ライバルを買収して相手製品を自社で売る場合がある。
オラクルには独自のFSがあるんで、死蔵させて潰す選択をしただけ。

696 ：

>>695
> オラクルには独自のFSがあるんで、死蔵させて潰す選択をしただけ。
何言ってんだ? Solarisで使ってるだろ。
まさかbtrfsのことじゃないか?

697 ：

ZFS Storage Applianceとか全然売れてねぇけどな
遅すぎるわ

698 ：

商用ファイルサーバなら既にIsilonがあるしなあ。

699 ：

調べてみるとbtrfsも重複排除はできるようでした
https://btrfs.wiki.kernel.org/index.php/Deduplication
でもこれWindows 2012のNTFSのデータ重複除去と同じく
書き込み時に重複排除してくれるものではなさそうです

700 ：

btrfsでその手の付加機能使うのは、まだ怖すぎる。。。
やっぱFSみたいな物は、昔から言われてるけど、企業がお金かけて作らないと
厳しいねぇ。
ドッグフードをガシガシ食って、主要部分だけでもバグ潰ししないと、いつまで経っても、
ドッグフードのまま・・・

701 ：

zfsでいいからgrowつけてー

702 ：

btrfsの重複排除は使ってるっていう情報が見当たらないですね
重複排除と透過圧縮とファイルのチェックサムがあって
わりと使われていそうなのはZFSだけみたいなんでZFSを使ってみることにします

703 ：

なんでみんなZFSなんだよ！
Linuxには、ext4っていう最先端技術が一杯盛り込まれた優れたファイルシステムがあるだろう？

704 ：

ORACLE様ならbtrfsやZFSなんての無視してASMでいいやん

705 ：

>>677
ext4 のチェックサムはメタデータに対してなんですね
何か勘違いしてました
ZFSでもファイルデータの修復ができるのはRAIDZとかで冗長化している場合だけですよね
ファイルのデータに対してチェックサムじゃなくて誤り訂正符号が
付けられるファイルシステムは聞いたことないですし
もしかして3-way mirrorかRAID6なら(そんな頻繁に起こると思いませんが)データ化けが起ころうが訂正できるのかな
いずれにせよlessfsってのとbtrfsの重複排除機能の情報は少ないのでZFSにしてみます

706 ：

そんなに誤り訂正欲しきゃ
RAID5+0でもRIDE6+0ででも組めばいいのに

707 ：

>>703
zlib圧縮すらstableでないfsじゃぁねぇ…。

708 ：

RAID6も故障Diskが既知でないと訂正できないみたい。
正直、データの整合性はHWに任せてOKと思うんだけど…

709 ：

>>707
stableじゃない事がなんなんだ！
皆でドッグフードの不味い部分をもっとガツガツ食べようぜ

710 ：

誤り訂正はできたら良いなってところで
透過的圧縮と特に重複排除が優先して使いたい機能です
lessfsで良いじゃないかってところなんですが情報が少なくて躊躇してます・・・
よく考えたら3-way mirrorやRAID6にしようがファイルの読み出しで
きっと毎回全部のディスクからデータを読んで比較なんかしてないですよね
mdadm はそんな設定があるのかな?
ZFSはファイルを読んだときにチェックサムが合ってなければ
RAID-Zから復旧してくれるんだろうと思います

711 ：

>>710
おまえがそもそもRAIDがなんなのかすら理解できていないことは理解できた

712 ：

面倒くせーな…
だったらEMCでも買えよ

713 ：

>>710
RH系だとraid-checkってスクリプトがスケジュールに登録されてて
週一でアレイの整合性チェックが実行されるはず
mdが内部でどんな処理してるのかまでは知らないけど
確かにRAID6なんかでデータ部の修復までしてくれたら嬉しいわな

714 ：

気にしすぎなんじゃないかと思うが

715 ：

>>710
mdadmにそんな仕組みはないみたいだぞ
http://serverfault.com/questions/391922/linux-mdadm-software-raid-6-does-it-support-bit-corruption-recovery
http://www.spinics.net/lists/raid/msg32814.html
もしディスク間で書かれているデータが異なっていたら
checkでmismatch_cntが増える
http://tkyk.name/blog/page/10/
で >>682-683 のとおりRAID1(2-way mirror)やRAID5なら
どちらが正しいか分からない
3-way mirrorやRAID6なら修復できるのかは知らないけど
重複排除を使いたいならZFSで良いんじゃないか？

716 ：

どんだけ大容量のファイル使ってんだかしらんが
数世代前でも無い限りRawデータだってCRCぐらい付いてるだろ

717 ：

まず、HDDにはセクタ単位でECCがついている。
このため、かなりの数のbitが同時に都合よく化けない限り、エラー訂正できる。
(もちろんエラーが、検出は出来ても訂正は出来ない場合にはリードエラーとなる)
そして、これは推測だけど「訂正可能なレベルのエラー」の中で、ある程度の回数だとかbit数だとかの規定値を超えたら
それはファームにより「不良セクタ」としてマークされ、代替処理が行われると思われる(OSからは見えない)。
一方、RAID456で使われているのは「パリティ」で、これは誤り訂正も出来ないし
エラー検出能力もきわめて低い。
しかし、「欠損」つまりどこのbitでエラーが起きたのか確実にわかるケースに限定すれば
正確に補完する能力があり、容量効率も良い。
これの欠損が、物理的な故障にぴたりとあてはまる。

718 ：

というのが俺の認識。

719 ：

CRCと言っても幾つもあって、訂正できるのもある。
訂正できるものでRAIDで使われているものもある。

720 ：

なんでZFSスレ すぐdat落ちしてしまうん？

721 ：

>>717
つ http://ja.wikipedia.org/wiki/RAID#RAID_6:_.E3.83.96.E3.83.AD.E3.83.83.E3.82.AF.E5.8D.98.E4.BD.8D.E3.83.BB.E8.A4.87.E6.95.B0.E3.83.91.E3.83.AA.E3.83.86.E3.82.A3.E5.88.86.E6.95.A3.E8.A8.98.E9.8C.B2

722 ：

RAID-5・6の欠点はパリティ更新時の障害によるサイレントクラッシュであって、
パリティの算出手法そのものには、まあ問題ない。

723 ：

そこまでRAID5やRAID6に不満や疑義あるならEMCでも使えばいいじゃん

724 ：

>>721
708でも書いたんだけど、エラー位置が既知の場合しか訂正できない様に
読めるんだけど。
普通はそういうのは誤り訂正符号とは言わないと思う。(個人的感想)
これを誤り訂正可能というなら、ただのパリティも誤り訂正可能だよ。
もちろん世の中すべてのRAID6の実装を知ってるわけでなく、wikipediaの
記述に関してだけ言っています。

725 ：

>>724
それが所謂サイレントクラッシュな訳だが。
誤り訂正符号で治せないのと、破損位置が分からないのは、
別の問題じゃねーの。

726 ：

>>724は、>>717に対する>>721の良く分からないコメントに(横から)レスしました。
ECCと呼ばれるものはエラー位置が未知の状態で訂正します。
(パンクチャ/デパンクチャしたりもしますが…)
ECCでは、エラー位置が分からないのと訂正不能なのは同じ問題です。
ECCを採用するのは符号化率や計算能力とのトレードオフになるので、
エラー位置が分かることになっているRAIDでは採用しないのも当然と思います。

727 ：

> ZFSでもファイルデータの修復ができるのはRAIDZとかで冗長化している場合だけですよね
RAID Z でないものも zpool scrub かけてエラーがあった場合に
checksum からなんとかできる程度の修理はしてくれる > ZFS
限界はあるけど．
っていうかどの程度までリカバリしてくれるのかは良く知らないのだ

728 ：

ZFSならmirrorからでも修復は可能
あと複数Diskで冗長化してなくても、zfs set copies=xでファイル書き込み時に同一Disk内の複数の箇所に分散コピーできる
素直にHDD増やした方がいいけどね

729 ：

>>720
話すネタがないから。

730 ：

zolってどーなってるの？

731 ：

ReFSってもう一般向けでも使えるんだな
http://www.k-php.com/lib/uploda/src/file703.png

732 ：

>>731
Windows Server 2012からね。
今のところWindows8とかのクライアントOSには載ってないよ。
重複除去使いたいからNTFS使ってるけど(´・ω・｀)

733 ：

ZFSとbtrfsって比較してる奴は……勝負になると思ってんのかなぁ？
全然違うじゃない
……名前の格好良さが！
（SunとOracleの信頼の差というのと、初出の安定感とかもあるけどさ！使いたい技術ってまず名前で決めるじゃない！）

734 ：

巣に帰ってどうぞ

735 ：

Btrfsってあと何年でstableになるんだろう。
ZFSのRaidzは数増やせないから不便で不便で(´；ω；｀)

736 ：

速度的には同じくらいなん？

737 ：

ZFSと比較はしたことはないがスナップショット取るとIOが固まるとか
スナップショットを削除するとIOが固まるとか時々deadlockが発生するとか
速度以前の問題。着実に改善はされてるがまだまだ。

738 ：

ext5のが先にくるよ

739 ：

fedora18ででたファイルシステムってどうなの？

740 ：

>>739
なんていうファイルシステム?

741 ：

>740
btrfsでしょ
昨日やってみたよ

742 ：

FedFS のことかな。
>>741
btrfs は前からなかったっけ。

743 ：

dragonflyBSD hammerの方が着実に実績を積んでる

744 ：

>>741
ググってから発言してくれ頼む
>>742
うん、それ
うちではインストールが途中で止まったから諦めた

745 ：

>744
そうですか
btrfsを選択してOSをインストール出来るようになったのはfc18からじゃない

746 ：

>>744
ファイルシステム名くらい最初から書けよ……。

747 ：

アホ二人

748 ：

ReFS Activator for Windows 8
http://www.firstever.eu/en/refs-activator-for-windows-8/
;(；ﾞﾟ'ωﾟ');

749 ：

Server 2012のシステムファイルをそのまま配布しているので真っ黒

750 ：

そもそもボラクルにやる気があるのか

751 ：

>>750
btrfsのことならメイン開発者はもうオラクルにはいないぞ

752 ：

なに！
ならもうBtrfsはオワコンなのか

753 ：

始まってすらいなかったような・・・

754 ：

早くbtrfs捨ててZFSを突っ込めばいいのに……

755 ：

FreeBSD, OpenBSDと共同で、OpenZFSとか作れないものなのかしらん。
ライセンスは、GPLv2とBSDのデュアルライセンスで

756 ：

また初めから実装するのは無駄だしBSDと共同はないだろ

757 ：

その方向ならHAMMERとかどうなん。使ったことないからよく知らないけど。

758 ：

HammerをOpenBSDやデフォルトにしてほしい

759 ：

だからZOLどうなってンのよ。

760 ：

>>759
一向にstable出ないけど1,2ヶ月にいっぺんくらいはrc更新されてるよ。

761 ：

FUSEベースのMicrosoft「exFAT」実装、「fuse-exfat 1.0」がリリース
http://sourceforge.jp/magazine/13/01/22/0452214

762 ：

>>760
返信ありがとう。気長にstable出るの待つかあ。
>>761
これでさらにexFAT/GPTで起動が出来れば、
USBメモリがより安全になり使い道広がるんだが。

763 ：

Windowsに他ファイルシステムを使えるようにするフリーソフトは何故ないの

764 ：

>>763
何故無いと思うの？

765 ：

Win版FUSEであるDokanもあるし、何が無いんだ？

766 ：

DokanてWin8未対応じゃなかったっけ

767 ：

互換モードでインストールできて動くんじゃなかったっけ

768 ：

つか、>>765-767のやり取りこそ>>763の思う壷だろ

769 ：

何かまずいか?

770 ：

煽りメソッドとかいう下らないのだろどうせ

771 ：

Dokan上でencfs4win動かしたらなんか動作が怪しかった

772 ：

ext4をWinで使いたいです＞＜

773 ：

zfsで定期的にスナップショット取ってるんですけど
スナップショットから特定のファイルだけ削除することは出来ますか？

774 ：

この記事がすごくおもしろかったんだけど、
【清水理史の「イニシャルB」】 予想以上に便利な記憶域スペースやSkyDrive連携
Windows 8＋NUC＋Thunderboltで作る自宅サーバー - INTERNET Watch
http://internet.watch.impress.co.jp/docs/column/shimizu/20130122_582241.html
win8の「記憶域スペース」と同等なことをLinuxで実現できるファイルシステムってあるのかな？
いまはLVMで 1TBのHDDを4本束ねて 4TBのボリュームを1つ作っているけど、
どれか1つでもHDDが欠けると、ボリューム全体が見えなくなってしまうよね。
ZFSは、ソフトウェアRAIDとLVMの「あいのこ」みたいな認識を持っているのですが(私の不勉強でしたらすみません)
ZFSは、Raid1をやりつつオンラインで領域拡張をしたり、ボリュームを構成しているHDDの一台が壊れても、
マシンを止めたりファイルシステムをアンマウントせずともHDDの付け替えとかできるの?

775 ：

>>774
Linux NativeのZFSを使ってるけど、
1T4本なら3Tのディスクが確保できるよ。RAIDZ1というキーワードで
google検索すると、機能の説明や設定方法がいろいろ出ているので、
そちらを参照。
オンラインで切り替えが出来るか、自分も不勉強だったが、SATAのコネクタは
OSが起動中に抜き差しが出来るみたい。年末に会社の備品の整理をした時、
大量のHDDをこの手を使って、データのチェックをしたり、内容消去を
したが、チェックに使ったLinuxマシンは一度も再起動せずにすんだ。
なお、ZFSには一応スペアディスクの機能があり、障害時にはこれに切り替わる
はずなんだが、うまく動かなかったので、単純なRAIDZ1にして使っていた。
その時のバージョンはrc8で、昨年の5月の連休にテストしたから、
今のバージョンでは動くかもしれない。

776 ：

>>774
冗長性を持たせた vdev (mirror, raidz, raidz2) を使えば大丈夫だよ。
箱は↓このへんがおすすめ。
http://www.supermicro.com.tw/products/chassis/2U/826/SC826BE16-R1K28LP.cfm
LSISAS2008 や LSISAS2308 が乗った HBA を使えば、sas2iciru で故障したドライブの
LED を光らせたりとかもできる。

777 ：

2012の記憶域プール/記憶域スペースは、zfsで言うなら、zvolを切り出すときにzvol単位で冗長性を指定できる感じだと思ってる
zfsではプール(を構成するメンバ)単位での指定だから、2012の方が柔軟なのかも
冗長性不要のものも混ぜられるから

778 ：

>>775
＞SATAのコネクタはOSが起動中に抜き差しが出来るみたい
それはシステムによる
コントローラ、電源、OS全部対応して初めて使える

779 ：

>>778
なるほど、前に試した時には認識しなかったり、
Linuxがカーネルパニックになったりしたけど、年末に
試したシステムは、マザーボードが新しいヤツなので
オンライン交換に対応してたのか。

780 ：

>>774
今のLVMってthin provisioningやraid 1/4/5/6が統合されたんだけど誰も使わないからノウハウが広まらなくて誰も使わないスパイラル

781 ：

>>780
その辺、fsまで統合しないといまいち気持ちよくならないしなぁ。

782 ：

すみません、最近RAID1の機能を内蔵した外付けハードディスクがありますが、
こういうの↓って、Linux で使えるんでしょうか？
http://www.iodata.jp/product/hdd/hdd/hds2-ut/

783 ：

>>782
くだらねえ質問はここに書き込め！ Part 204
http://engawa.2ch.net/test/read.cgi/linux/1358204325/

784 ：

>>782
普通の外付けHDDとしては特に問題なく使えるだろうね。
ただ、RAIDの診断・管理機能はWindowsでしか使えないだろうね。

785 ：

>>783
ごめん、くだ質と間違えてレスした。

786 ：

みなさんレスありがとうございます。とても勉強になりました。
この Win8 の記憶域スペースや、VVAULTみたいなのが
Linuxでもできたらおもしろいなと思いました。
自分の場合は、4TBの前は 320GB*4 (1.28TB) のボリュームだったんだけど、
1.28TBが足りなくなってきたら、以下のようにやってました。
・いったん、べつのHDDにまるごとバックアップ
・1.28TBのLVMのボリュームを削除、320GB*4 の HDDは外す
・1TB*4 の HDD を買ってきて付けて、LVMで4TBのボリュームを作る
・バックアップからもどす
こういうのをもっとスマートにやりたい。
でも、LVMの場合、オンラインリサイズできるかどうかは、そのボリュームのファイルシステムに依存しちゃいますよね。
(いちおうxfsをつかっています)

787 ：

>>783
すみません、「くだ質」に行ってきます。
>>784
ありがとうございました。

788 ：

btrfsがやる気あるのかないのか
待てないのでzfs on linuxで構築始めた

789 ：

>>786
mhddfsあたりじゃ不足なのか?

790 ：

ほうそんなものがあったのか
初代Windows Home ServerのDE（Drive Extender）ぽいな

791 ：

>>786
pvmove、って思ったけどオンラインのままデータ移動できるだけで対して手間変わんねーか

792 ：

>>786
いやそれで十分でしょ
わざわざオンラインリサイズする必要ないような

793 ：

>>790
ただ書き込みのパフォーマンスはあまり良くなかった気がするな

794 ：

RAID 5/6 Support Finally Comes To Btrfs
http://www.phoronix.com/scan.php?page=news_item&amp;px=MTI5Mjc
stableカーネルに降りてくるのはいつになるか。

795 ：

http://blog.keshi.org/hogememo/2012/12/26/tuning-xfs-physical-sector-size
sectszなんて注目したことなかったなあ

796 ：

>>786
前後読んでないので的はずれならごめん
xfsは拡張のみリサイズに対応してる。
電源とsataの口に余裕があれば、オンラインでのリサイズに支障はないよ。

797 ：

>>793
パフォーマンス関係ないよ。
mhddfsは複数のドライブをまとめて
一本に「見せて」いるだけ。

798 ：

>>797
一本に「見せる」ためにオーバーヘッドが発生してるわけで
ある程度のパフォーマンス低下は避けられないよ
しかもfuse実装だし
まあ倉庫用ととしては問題ない速度出るし、俺自身愛用している

799 ：

>>798
そんなクリティカルな業務に利用するもんじゃなし
「ある程度」なんて適当なこと書かんでもw

800 ：

> ZFSは、Raid1をやりつつオンラインで領域拡張をしたり、
RAID-Z系はオンライン拡張NG(FreeBSDしか知らないけど，
たぶんソラリスでも同じ?)．
ただしRAID1 が要求なら，RAID1じゃなくてRAID1類似の
「同じデータを複数記録する」モードなら
動的領域拡張含めて対応OK
> ボリュームを構成しているHDDの一台が壊れても、
> マシンを止めたりファイルシステムをアンマウントせずとも
> HDDの付け替えとかできるの
ZFSとしては楽勝．すでに出てるようにOS側・ドライバとかの
対応の問題．FreeBSDでは出来てるです

801 ：

>>800
> > ZFSは、Raid1をやりつつオンラインで領域拡張をしたり、
>
> RAID-Z系はオンライン拡張NG(FreeBSDしか知らないけど，
> たぶんソラリスでも同じ?)．
> ただしRAID1 が要求なら，RAID1じゃなくてRAID1類似の
> 「同じデータを複数記録する」モードなら
> 動的領域拡張含めて対応OK
RAID-Z も大丈夫だよ。
> > ボリュームを構成しているHDDの一台が壊れても、
> > マシンを止めたりファイルシステムをアンマウントせずとも
> > HDDの付け替えとかできるの
>
> ZFSとしては楽勝．すでに出てるようにOS側・ドライバとかの
> 対応の問題．FreeBSDでは出来てるです
HBA でOS上のデバイス名の特定とエンクロージャーのスロット番号の特定って
どうやってる？

802 ：

オンライン拡張はZFSの開発理由だからね
メモリは刺せば全容量がすぐ使えるのにHDDは刺した後もなんだかんだと色々面倒臭い
ってのが開発動機だったってあのsunのページどこいったんだろ

803 ：

ZFSでいろいろ実験したときに、SSDと内蔵HDD、外付けUSBのHDDで
Poolを作ってみた。容量は全てのストレージの合計となり、SSDに空きが
ある時には読み書きも速かったが、SSDがいっぱいになったらショボーンな
結果に。アクセスの頻度をみて、中のデータをSSD->内蔵HDD->USBと
再配置するような高等な機能は無いみたい。
何か設定があるんだったけ？

804 ：

SunがOracleに買われてから、失われたwebページが大量にあるんだよな...

805 ：

>>803
L2arc

806 ：

>>803
キャッシュとかL2ARCとか
よくは知らんが、単にプールの1メンバーとしてSSD足したらそりゃそうなるわな

807 ：

>>802
これ？
tp://web.archive.org/web/20090412131623/http://jp.sun.com/communities/0612/feature01.html

808 ：2013/02/10

>>807
うんソレ
Sunの読み物って結構面白いのあったのにね