トップページ⇒linux
1001コメント304KB

/**ファイルシステム総合スレ その 9 **/

レス数が900を超えています。1000を超えると表示できなくなるよ。
0001login:Penguin2008/10/26(日) 15:18:36ID:VYy55fXH
過去スレ
　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/1173530292/
07
08 http://pc11.2ch.net/test/read.cgi/linux/1190788761/
0809login:Penguin2009/03/09(月) 00:57:57ID:GV2fXnbN
>>808
inotifyを使った習作みたいなプログラムだね。
このinotifyを知った時には、ファイルに変更があった時にだけ
リモートサーバーに変更差分をpushするようなデーモン出来るかなー
と思ったんだが、やはりみんなそう思うらしくて、
http://code.google.com/p/lsyncd/
に、そういうLive Syncing (Mirror) Daemonがあったりする。
0810login:Penguin2009/03/10(火) 17:29:28ID:fa0QTRY4
btrfsは名前が悪い。絶望的に。

バターfsなんて恥ずかしくて使えない。
0811login:Penguin2009/03/10(火) 17:30:46ID:UYNGOKpb
バーターって読むんだけど・・・
0812login:Penguin2009/03/10(火) 17:32:43ID:YEjvX6c1
作者がbutter-fsだって言ってるじゃん
0813login:Penguin2009/03/10(火) 17:39:37ID:UYNGOKpb
おお、ほんとだ。すまん。
0814login:Penguin2009/03/10(火) 17:50:40ID:YQAoSTI+
>>810
>>518

罵倒fsだってさ
0815login:Penguin2009/03/10(火) 20:07:48ID:yDC62HHM
>>814
バトーFSだと強そうじゃね？

mke2fs　-jv　で1Tのハードディスク128Gと872Gに分けてフォーマットしたら
872Gの方が途中でセグメンテーションフォルトが起きました
mke2fsは大容量対応していないんですか?
0816login:Penguin2009/03/10(火) 20:09:03ID:OxRS8Iom
お前んとこだけだよ
0817login:Penguin2009/03/10(火) 21:01:28ID:yDC62HHM
>>816
んじゃ、HDDの初期不良かな
0818login:Penguin2009/03/11(水) 00:50:24ID:oxPAi9BH
HDD: WD10EADS

xfs
1TBのフォーマットは2秒くらいで終わる。

# 大ファイルの操作
1.2Gのファイル4個をコピー
$ time -p cp * /mnt/backup/
real 273.95

コピーした1.2Gのファイル4個を削除
$ time -p rm -f *
real 0.20

# 小ファイルの操作
MPlayerを解凍
$ time -p tar jxf MPlayer-1.0rc2.tar.bz2
real 4.83

解凍したMPlayerを削除
$ time -p rm -rf MPlayer-1.0rc2
real 4.22

# 中ファイルの操作
mp3ファイル556個(1ファイル2-3MB)計1.4Gをコピー
$ time -p cp *.mp3 /mnt/backup/
real 41.64

コピーしたmp3ファイルを削除
$ time -p rm -f *
real 1.46
0819login:Penguin2009/03/11(水) 00:51:59ID:Q/Pii7+/
三国志ヲタには馬騰fs
0820login:Penguin2009/03/11(水) 00:52:32ID:oxPAi9BH
ext4
1TBのフォーマットは4-5分かかる。

# 大ファイルの操作
1.2Gのファイル4個をコピー
$ time -p cp * /mnt/backup/
real 273.64

コピーした1.2Gのファイル4個を削除
$ time -p rm -f *
real 0.20

# 小ファイルの操作
MPlayerを解凍
$ time -p tar jxf MPlayer-1.0rc2.tar.bz2
real 5.76

解凍したMPlayerを削除
$ time -p rm -rf MPlayer-1.0rc2
real 6.46

# 中ファイルの操作
mp3ファイル556個(1ファイル2-3MB)計1.4Gをコピー
$ time -p cp *.mp3 /mnt/backup/
real 41.51

コピーしたmp3ファイルを削除
$ time -p rm -f *
real 1.45
0821login:Penguin2009/03/11(水) 00:54:35ID:oxPAi9BH
reiserfs3
1TBのフォーマットは30秒くらいで終わる。

# 大ファイルの操作
1.2Gのファイル4個をコピー
$ time -p cp * /mnt/backup/
real 283.27

コピーした1.2Gのファイル4個を削除
$ time -p rm -f *
real 0.19

# 小ファイルの操作
MPlayerを解凍
$ time -p tar jxf MPlayer-1.0rc2.tar.bz2
real 4.83

解凍したMPlayerを削除
$ time -p rm -rf MPlayer-1.0rc2
real 4.24

# 中ファイルの操作
mp3ファイル556個(1ファイル2-3MB)計1.4Gをコピー
$ time -p cp *.mp3 /mnt/backup/
real 41.75

コピーしたmp3ファイルを削除
$ time -p rm -f *
real 1.50
0822login:Penguin2009/03/11(水) 00:56:16ID:oxPAi9BH
jfs
1TBのフォーマットは1秒くらいで終わる。

# 大ファイルの操作
1.2Gのファイル4個をコピー
$ time -p cp * /mnt/backup/
real 280.49

コピーした1.2Gのファイル4個を削除
$ time -p rm -f *
real 0.19

# 小ファイルの操作
MPlayerを解凍
$ time -p tar jxf MPlayer-1.0rc2.tar.bz2
real 5.02

解凍したMPlayerを削除
$ time -p rm -rf MPlayer-1.0rc2
real 4.33

# 中ファイルの操作
mp3ファイル556個(1ファイル2-3MB)計1.4Gをコピー
$ time -p cp *.mp3 /mnt/backup/
real 40.73

コピーしたmp3ファイルを削除
$ time -p rm -f *
real 1.46
0823login:Penguin2009/03/11(水) 00:57:37ID:RdiNL0Kx
シングルタスクしかしない人ですか？
0824login:Penguin2009/03/11(水) 01:07:56ID:Tlh+Q3Rr
どれを使っても大差ない感じなのかな。そうなるとシステム負荷が軽いのが良いな。
0825login:Penguin2009/03/11(水) 01:09:16ID:oxPAi9BH
xfsは小ファイルの処理が非常に遅いと感じていたので、
HDDを買い足したついでにテストしてみた。
どのファイルシステムでも小ファイルの処理には
それなりに時間がかかるものなんだな。
(kernelとかだともっと差がつくようだが)

HDDのヘッドが退避しないうちにさっさとテストしたつもりだけど、
どこか手違いがあったのかもしれない。
あるいはWD10EADSが低速回転だから差がつかなかったのかな。

個人的なバックアップ用途としてはxfsも悪くないのかもしれない
0826login:Penguin2009/03/11(水) 01:38:14ID:Tlh+Q3Rr
>>825
自分もxfsが細かいファイルにもっと時間が掛かると思ってたw
ちなみに使用しているカーネルのバージョンは?比較的最近のカーネルかな。
0827login:Penguin2009/03/11(水) 04:29:15ID:KO510Owq
>>823
どんな形であれ、せっかくテストしてくれているんだから、そんな言い方をしたら失礼だぜ？
0828login:Penguin2009/03/11(水) 05:15:14ID:Oxh4Vyl/
>>825
$ tar tjf MPlayer-1.0rc2.tar.bz2 |wc -l
3260

もう一桁多いのを試してほしいような…
つうか一個のディレクトリに大量に置かないと有意な差は見えないと思う。
0829login:Penguin2009/03/11(水) 08:03:47ID:4YDbCnMJ
XFSはあらゆる場面において
最も速く、最も安全に使えるファイルシステムです
0830login:Penguin2009/03/11(水) 08:55:12ID:hFe1ZwTZ
釣るつもりならもっと上手く書けボケ老人
0831login:Penguin2009/03/11(水) 10:59:47ID:4YDbCnMJ
釣りではありません
真実を述べているだけです
0832login:Penguin2009/03/11(水) 11:10:01ID:rfDVx5RA
>>831
では適切な検証をデータ込で提示してくださいな
スレ住民も条件の選び方から見て自分にあったFSか見極めるでしょうから

「そんなことしなくても自明です」なんて言ったら電波確定
0833login:Penguin2009/03/11(水) 11:58:04ID:4YDbCnMJ
何をやってもXFS批判を噴出させるのが
このスレの住人というものです
0834login:Penguin2009/03/11(水) 12:36:41ID:EgNJdZ2x
普段使うだけならjfs悪くないよ。
xfsはgentooでいろいろでかいのビルドするとき遅いと感じる。
0835login:Penguin2009/03/11(水) 12:47:07ID:KEpL3SfB
>>825
単一ディレクトリに多数の小ファイルがある場合XFSは速いけど
多数のディレクトリに分散してそれぞれ100個程度の小ファイルがある場合は遅い
後者の場合だとext4のほうが速かった
>>834が遅いって言ってるのも、これだと思う
0836login:Penguin2009/03/11(水) 18:58:29ID:VdtLCfNF
家庭内的にjfs使い始めてそろそろ2年だが問題ないなぁ。
Maildirのメールサーバだから細かいファイルが沢山できる感じだが
特に問題がおきたことはない。
(スパムを全部取っているから数は結構あるな・・・)

引っ越ししたあと、家電が増えてブレーカー落ちやすくなったんだが
バカスカ落としても何もなかったように起動してくる。
偉いぜjfs。
というわけでもっとでかい運用状況聞きたいぜ。
0837login:Penguin2009/03/11(水) 21:17:13ID:8ECCLmHd
カーネルの展開が遅いって書かれてたのに、何でMPlayerの展開でテストしてんだか…
しかもHDDの型番はともかく、他はマシン構成はおろか、フォーマット時のオプションすら書かれてないし
テスト結果はかなりウソくさい

何しろウチのML115初代 ＆ AthlonX2 5000+ ＆ 2GB DDR2 × 2 ＆ WD5000AAKS ＆EN8600GT ＆ SoundBlaster Audigy無印って構成のPC上から
X ＆ KDE 4.2.1立ち上げて、その中でkonsoleからsudo emerge texliveしながら、隣のタブでMPlayerのtar玉解凍したって
ウチのext4はそんなにはかからないから

ぶっちゃけ、上記の状態ですら time tar xjf MPlayer-1.0rc2.tar.bz2 なら
real　 　0m3.224s
user　 　0m2.980s
sys　 　 0m0.250s
俺はext2とext4しか使っていないから他は追試出来ないけど、どうせ他のテスト結果もウソっぱちだろう
0838login:Penguin2009/03/11(水) 23:12:10ID:rkEwTD3M
z/Linuxに向いてるのは
どのファイルシステムですか？
0839login:Penguin2009/03/11(水) 23:42:26ID:IrA1hiXP
>>836
そろそろクラッシュする頃だな
0840login:Penguin2009/03/12(木) 00:12:25ID:QKWWjyLf
>>836
大規模システムで使っているＹＯ
小さいファイルが多いなら、おぬぬめ
0841login:Penguin2009/03/12(木) 05:39:50ID:Uu2UFoYU
>>837
> 何しろウチのML115初代 ＆ AthlonX2 5000+ ＆ 2GB DDR2 × 2 ＆ WD5000AAKS ＆EN8600GT ＆ SoundBlaster Audigy無印って構成のPC上から
> X ＆ KDE 4.2.1立ち上げて、その中でkonsoleからsudo emerge texliveしながら、隣のタブでMPlayerのtar玉解凍したって
> ウチのext4はそんなにはかからないから

フォーマット時のオプションすら書かれてないし
テスト結果はかなりウソくさい。

というのはさておき、

> 他は追試出来ないけど

rm -rf MPlayer-1.0rc2 はできるはず。

あとマシン構成はいらないけど、
(サウンドカードとかグラボとか関係あるのかな)、
WD5000AAKSの場合は新旧プラッタがあるから
そこを書かないとね。
320GB*2プラッタ品で7200rpmだったら、
WD10EADSみたいに3プラッタ5400rpm品より
速くて当たり前のような気がする
0842login:Penguin2009/03/12(木) 05:59:17ID:Gl1f5D2g
無意味に割り込みかけてくるサウンドカードとか、無駄にバスを占有する
ビデオカードとかだと影響するんでないかい。

ついでに適当な計測結果
Dell INSPIRON 1501 + 2.6.26 + reiser3
ほぼ無負荷
$ time tar xjf MPlayer-1.0rc2.tar.bz2

real 0m6.101s
user 0m4.932s
sys 0m1.124s

$ time rm -rf MPlayer-1.0rc2

real 0m0.756s
user 0m0.008s
sys 0m0.712s
0843login:Penguin2009/03/12(木) 08:24:11ID:q/of3Wvv
ext3で50GBとかのファイル数個をrmすると、50GBのファイル書くのと
同じくらい時間がかかるんだけどこれは仕様？

ディレクトリエントリ操作するだけなんだから一瞬で終わってしかるべきと
思うんだが・・・
0844login:Penguin2009/03/12(木) 12:01:29ID:fUWg+Y+2
>>843
このスレで何度も話題になっているが、
なぜそうなっているのか技術的理由を書ける人が
このスレに現れたことはない。
0845login:Penguin2009/03/12(木) 12:39:28ID:Gl1f5D2g
>>843
inodeを忘れないであげてください。

誰かがそのファイル掴んでいる状態で削除すれば、
ディレクトリエントリ消すだけなので一瞬で終わる。
んで、放した瞬間にHDDがカリカリ言い始めるはず。

ということでinode(つうかメタデータ)の更新がすげー遅い。

0846login:Penguin2009/03/12(木) 13:30:20ID:FK4CPecw
そりゃbitmap使ってるfsの宿命ですがな。

つか、このスレの住人って読込み性能にあんまりフォーカスしてないのはなぜ？
0847login:Penguin2009/03/12(木) 14:45:45ID:uwGP8iQx
読み込みは気になったこと無いなぁ。
0848login:Penguin2009/03/12(木) 20:47:20ID:/5waLCXS
去年のカンファレンスでプレゼンターが削除速度を速くしたくて・・・と話していたら
Ted Tsoが割り込んでクラッシュ時の信頼性をあげるために、わざとそうしていて云々と自説を述べ始めて、
スピーカー困惑。
・・・かと、思ったらそこにさらにLinusが割り込んで、「ふざけるな。オレもふだんイライラしてるんだ。高速化しる！」とか自説を
述べ始めて、二人がプレゼンターそっちのけで議論をつづけるので、セッションにすごい微妙な空気が流れたことが

発表者の中の人がかわいそうすぎます
0849login:Penguin2009/03/12(木) 21:06:32ID:Q9tPCjh3
何度も言うが
難しいことを考えずにXFSを使え
0850login:Penguin2009/03/12(木) 21:15:11ID:8EggFbE/
さすがXFS教。言うことが違う。
0851login:Penguin2009/03/12(木) 21:18:29ID:HGzIMQq7
ここは、btrfsに期待
0852login:Penguin2009/03/12(木) 21:19:13ID:2VoPly+Y
結論 JFSでまた〜り
0853login:Penguin2009/03/12(木) 23:23:22ID:RqJ4/lD8
プレゼンターも、突っ込んでやれよ。

俺は、Linusにつくね。
クラッシュ時の信頼性って言えば許されるとおもってんのか！
だから、ZFSみたいなのが作れないんだよ、と。
0854login:Penguin2009/03/13(金) 00:29:01ID:AmR0mtlJ
信頼性軽視するからLinuxのfsは他OSからportしてきたものでもアレなことに
なっているけどな。おまけに大して性能も出ていないし。
0855login:Penguin2009/03/13(金) 00:46:56ID:Xd/smKgF
いろんなFSを量産しているのも弊害だよなぁ
0856login:Penguin2009/03/13(金) 08:53:47ID:QyWnsw8e
>>854
信頼性重視なの？
0857login:Penguin2009/03/13(金) 08:55:22ID:QyWnsw8e
ごめん。読み違えたw
そうだよなー。
重視してるならReiserの時もあそこまでフレームが大きくならなかっただろうし。
0858login:Penguin2009/03/13(金) 20:05:10ID:DZg3JUvb
Solaris ZFSの基本的な仕組みを知る
ttp://www.atmarkit.co.jp/fserver/articles/zfs/01/01.html
0859 ◆IIiDC8JS7w 2009/03/13(金) 21:14:51ID:dlpFGOyH
たくさんのファイルを複数のディレクトリに
ファイルを作成したり、削除したりする時間を測定する
ツールがあるので、使って性能測定してみてください。
redhatの人とか、btrfsの評価で使ってくれている。

ttp://www.spinics.net/lists/linux-btrfs/msg02003.html
↑の最後のほうにコードが載ってます。
0860login:Penguin2009/03/13(金) 23:39:08ID:x6C+8Djd
ext4がXFSライクなデータ消失を起こしたようです。
ttp://slashdot.jp/hardware/article.pl?sid=09/03/13/1311252
0861login:Penguin2009/03/13(金) 23:41:42ID:E6JaImFf
一緒にすんなハゲ
XFSでこんなこと起きねえよ
0862login:Penguin2009/03/13(金) 23:43:52ID:JibFhBsj
>>861
最近クラッシュしたときに、書き込みしてなかったか？
ファイルサイズが同じでも中身が0で埋まってるファイルが
できてるかもよ。
rsyncでとってたバックアップも死んでるかもwwww
0863login:Penguin2009/03/14(土) 07:11:48ID:cN9wHfAO
fsのバグでもなんでも無いじゃないか。
http://slashdot.jp/hardware/comments.pl?sid=442678&cid=1530766
0864login:Penguin2009/03/14(土) 10:33:27ID:wTSiQHD4
>>859
ファイルシステムベンチマークなら、bonnie++が定番。
0865login:Penguin2009/03/14(土) 10:46:54ID:Fjttua0k
これってext3でも起こるよね。起こりにくいだけで。
>>863の最初の例なんか、
truncate -> writeで、write前に落ちれば
どのジャーナルモードでもデータが消えるんじゃないか?
すでに実行されていたとしても、ジャーナルにあって次マウントしたときにreplayされても。
0866login:Penguin2009/03/14(土) 11:40:29ID:tgz4pVHK
＞ rename("~/.kde/foo/bar/baz", "~/.kde/foo/bar/baz~") --- this is optional
＞ rename("~/.kde/foo/bar/baz.new", "~/.kde/foo/bar/baz")

は

unlink("~/.kde/foo/bar/baz~")l
link("~/.kde/foo/bar/baz", "~/.kde/foo/bar/baz~")
rename("~/.kde/foo/bar/baz.new", "~/.kde/foo/bar/baz")

にすべきだよな
0867login:Penguin2009/03/14(土) 14:45:40ID:NGZaZVb3
>>865
最初のはそうだけど、２つ目が問題なんだわ。

xfsはデフォルトでメタデータが先にコミットされるので、その直後に
クラッシュするとファイルシステムの構造的には不整合はないが、その
メタデータが指しているデータは存在しない。

で、xfsはメタデータがゴミデータを指してる状態で開けると、何が
見えるかわからん（古い/etc/passwdのブロックかもしれん）から
セキュリティ的な問題があるよね、ときちんとメタデータが指している
データを最初はゼロクリアした状態にしている（本来のデータがコミット
されたら当然そちらに付け替える）。

ext3等はデフォルトではデータが先にコミットされるので、２での問題は
生じ得ない。一方、xfsの順序は最高性能を発揮するためで、生まれた時代や
背景を考えると致し方ない。

POSIX的にはfsyncしてない限り、どちらの挙動も問題なしで、fsyncしない
アプリ開発者がPOSIXを理解してないというのが結論になる・・・が、
正直２の書き方って、すごい一般的だよね、さあどうしよう、という状況。

　hogehoge > fugafuga && fsync fugafuga.new && mv fugafuga.new fugafuga

とか直していくしかない。Ubuntuだっけ？にfsyncコマンドがあるのは
このためだろうと思われる。

もっとも、ドライブキャッシュがあるとfsyncすら保証してくれないので、
さらにバリア張らないととか延々と話が続くんだけど。
0868login:Penguin2009/03/14(土) 16:28:12ID:l9ZzVqeQ
blogの翻訳？
0869login:Penguin2009/03/14(土) 19:12:33ID:++9sa7SW
一時ファイルに書き込み→名前変更ってのは当たり前の技法だと思ってたけど
そうでもないのかな？
0870login:Penguin2009/03/14(土) 20:08:40ID:6p4fiq3F
>>869
いや、あたりまえの技法というコンセンサスはとれていた。ゆえにTed Tsoは仕様どおりだ！とか片意地はらずに直すと言っている。という理解
0871login:Penguin2009/03/14(土) 20:11:26ID:RgsfJUAA
しかしまぁ、仕様通りだから悪くない、と言っても汎用的なFSとしては使えないよなぁ
0872login:Penguin2009/03/14(土) 20:19:32ID:qHb4tz1u
でもそうやって理想の仕様よりも現実を優先していくとWindowsみたいになるわけだけだが。
一見すると謎仕様すぎて、分かってない連中にボロくそに言われるという。
0873login:Penguin2009/03/14(土) 20:21:09ID:Fjttua0k
>>867。
なるほど。
>>869もいってるけど、うまく書けたらリネームっていうのは、良くやるやり方なので、
確かにext3の挙動の方が安心できる気がしますね。

結局ext4での書き込みがext3より大幅に遅延するとしても、
ジャーナルに記録されていれば大丈夫な気がするのだが。
0874login:Penguin2009/03/14(土) 20:23:23ID:2PA7Wxqo
そしてHans Reiser恩赦に
0875login:Penguin2009/03/14(土) 21:23:11ID:Qv+bO9QY
壊れたメタデータのコミット先を教えるかわりに
FSの破壊を軽減する司法取引だな
0876login:Penguin2009/03/14(土) 21:57:26ID:wTSiQHD4
ZFSとかFS層の破壊防止を徹底してるから、
これからはそういう設計が定番になるんじゃないかな。

Btrfsはどうなんだろ？
0877login:Penguin2009/03/14(土) 23:59:37ID:1qF/srTZ
super_operations構造体のメンバ
freeze_fsやunfreeze_fsってwrite_super_lockfsやunlockfsから名前変えたのか？何故に・・
0878login:Penguin2009/03/15(日) 10:02:11ID:PCGBiEcT
>>872
これは現場ではうまくいっていたけど理想的な方法ではないのを、改めているのだと思うぞ。
0879login:Penguin2009/03/15(日) 10:18:44ID:xjkBDfQM
>>877
きまぐれ。
0880login:Penguin2009/03/15(日) 19:42:41ID:PU06YtSt
もう名前変更しなくていいようにメンバは

　struct struct0001_s {
　　member0001_t member0001;
　　member0002_t member0002;
　　member0003_t member0003;
　　...

として意味は仕様書と帳票で管理すべし。これならコードで
書く内容も迷うことが少なくていいし、順序がずれたらABI破壊バグと
すぐわかる。
0881login:Penguin2009/03/15(日) 20:01:52ID:mnUY72EV
>>879
だったら　やめて　ちょうだい
本気で好きになりそうだから
あなたの前では　きれいでいたいし
0882login:Penguin2009/03/15(日) 20:31:39ID:ReDUN6Ol
>>876
btrfsはZFSと同じくCOWで書くから、この問題は起こらない
0883login:Penguin2009/03/15(日) 20:34:14ID:kmO3PCzB
btrfsはなんでaddressingを128bitにしなかったの？ZFSに負けちゃうよ
0884login:Penguin2009/03/15(日) 20:56:32ID:LgaDmqJ8
>>881
吹いた
0885login:Penguin2009/03/15(日) 22:13:07ID:VfSmlfyi
デ♥フ♥ラ♥グ
0886login:Penguin2009/03/15(日) 23:37:34ID:mnUY72EV
>>884
歌詞の一部です　若かった昔を思い出させる
今夜のナンバー　１曲目は
長渕剛　素直
ttp://www.youtube.com/watch?v=cM-QvJI_RJQ
0887login:Penguin2009/03/16(月) 01:59:21ID:Gwa/wpQE
>>883
btr2fs誕生のフラグです
0888login:Penguin2009/03/16(月) 02:03:51ID:08WqhxTZ
>>883
アドレスが128bitだとIPv6を連想して不吉だから
0889login:Penguin2009/03/16(月) 15:19:00ID:fRtMFqd9
マジレスするとVFSが対応していない。
0890login:Penguin2009/03/16(月) 15:31:04ID:FfCxFL0P
ext3は罪な奴だな
fsyncを徹底すると遅すぎて使い物にならないし
fsyncをしなくても十分安全だから
fsync無しの更新を一般化させてしまった


ext4も、data=orderedがデフォルトで安全なはずなんだけどなぁ
遅延アロケーションはジャーナルのコミットを考慮しない言うのか
0891login:Penguin2009/03/16(月) 16:49:59ID:TUvh8KP2
extなんとかが最もポピュラーなのはなぜ？
歴史的な理由ですか？
0892login:Penguin2009/03/16(月) 18:13:10ID:4dJsZZR0
なんだかんだで愛されてるんだよ
0893login:Penguin2009/03/16(月) 18:59:45ID:XO5/u8kb
殺人よりはマシだからな（ワラ
0894login:Penguin2009/03/16(月) 20:55:40ID:fRtMFqd9
>>891
そのとおり。
ext2時代は事実上、それしか選択肢がなかった。
ext3時代はredhatが他のFSをサポートしなかった。FSの品質はテスターの数にめっさ依存するので
ディストロの対応重要。
0895login:Penguin2009/03/17(火) 03:29:17ID:j28XnUZ4
Don’t fear the fsync!
http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/
0896login:Penguin2009/03/17(火) 09:33:29ID:BGo9Cde8
教祖様は極東の言語でしか、お言葉を賜らないからなぁ。
lkmlやfsdevelでも議論を見たことがないし、
T'soのblogにコメントでもしてほしいぜ。

まぁ、下々のページにいちいちコメントなんてつけないか。
0897login:Penguin2009/03/17(火) 10:39:55ID:a4R8kExy
from Japanじゃなくてfor Japaneseの教祖様だから仕方ない。
0898login:Penguin2009/03/17(火) 10:59:40ID:NsAcifq/
数年前にLKMLで見たような記憶があるが。

そーいやDOUBTはどうなったのだろう？

0899login:Penguin2009/03/17(火) 11:06:54ID:BGo9Cde8
ttp://slashdot.jp/linux/article.pl?sid=06/07/11/0839251
ttp://devresources.linux-foundation.org/dev/doubt/
便所の落書の域を出ることなく終わったな
0900login:Penguin2009/03/17(火) 19:54:49ID:pcJNpNZy
okkyって言えば↓やってみた奴っている？
http://slashdot.jp/~okky/journal/469580

速くなるかなと思ってうちのOCZSSD2-1VTX250Gで試してみたけど
普通にmkfs.ext4したのと比べて速くなったような気がしないんだよな
つか、買ったばっかのSSDだからあんまり過酷なテストとかしたくもないしw
0901login:Penguin2009/03/17(火) 20:42:34ID:BGo9Cde8
>>900
ttp://mkosaki.blog46.fc2.com/blog-entry-833.html
ttp://tytso.livejournal.com/60368.html
0902login:Penguin2009/03/17(火) 22:41:41ID:AB0pyKFT
>つか、買ったばっかのSSDだからあんまり過酷なテストとかしたくもないしw

ならやんわりテストすればよろし
びみょーに寿命は伸びると思うよ
0903login:Penguin2009/03/18(水) 03:18:16ID:5gZEF53k
>>900
ext4だと強烈な遅延書き込みになっているからじゃない?
0904login:Penguin2009/03/18(水) 03:29:17ID:XmoCfEgT
↓のスレでHAMMER FSのBonnie++ベンチマーク取ってくれた人がいたから貼り。
なんかめっさ速くない？

dragonfly bsd どうよ
http://pc11.2ch.net/test/read.cgi/unix/1088515885/

Athlon64x2
メモリ2G
ad4: 953869MB <WDC WD10EACS-00D6B0 01.01A01> at ata2-master SATA150

nohistory: athlon64.x2,300M
------SequentialOutput--------SequentialInput---Random-
-PerChr---Block---Rewrite--PerChr---Block----Seeks--
34257 96 97652 40 71778 14 39591 97 932845 68 13087.0 23
------SequentialCreate--------------RandomCreate--------
-Create----Read----Delete---Create----Read----Delete--
57502 79 130264 99 18240 30 36341 48 123916 94 39858 66

nohistoryなし: athlon64.x2,300M
------SequentialOutput--------SequentialInput---Random-
-PerChr---Block---Rewrite--PerChr---Block----Seeks--
32760 85 96287 15 71640 17 39757 98 928711 59 49945.1 85
------SequentialCreate--------------RandomCreate--------
-Create----Read----Delete---Create----Read----Delete--
60186 91 130592 93 28627 39 64754 89 143084 102 32111 55
0905login:Penguin2009/03/18(水) 03:39:53ID:XmoCfEgT
誰か>>904の人と同じようなスペックの人、
BtrfsのBonnie++ベンチマーク取ってみてくれない？
↓の方法で修正してからmakeよろしく。

http://plaza18.mbn.or.jp/~moriban/linux/UsageOfBonnie.html

果たして ZFS vs Btrfs vs HAMMER の勝者は誰になるのか。
0906login:Penguin2009/03/18(水) 04:52:34ID:wF0j/2un
ext4なんて今更つかうわけがない
0907login:Penguin2009/03/18(水) 07:35:22ID:XmoCfEgT
>>900
なんかOSの仕組みとして、Windowsと比べてLinuxは
4Kランダム書き込みが少ないんじゃないかな？
VMwareとかでXP立ち上げたりしてると、
ただ単に起動するだけでもスゴい量の書き込みが発生してる。
それに対してLinuxは、書き込みはせいぜいlogとpidと/tmp/ぐらいじゃない？

大量の書き込みが発生するようなデーモン（PostgreSQL、MySQLとか）も、
できるだけまとめてから書き込もうとするから、
4Kランダムよりシーケンシャルが多いような気がする。

細かい書き込みがあるのは、メールサーバぐらい？
0908login:Penguin2009/03/18(水) 12:44:49ID:5gZEF53k
>>907
かの懐かしいnntpdなんて大量のファイルの読み書きをするサーバの代表だったけど、
今は日本ではほとんど使われてないなぁ。

あとはvirus scanner周りかな。
レス数が900を超えています。1000を超えると表示できなくなるよ。