09/03/12 05:39:50 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品より
速くて当たり前のような気がする
842:login:Penguin
09/03/12 05:59:17 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
843:login:Penguin
09/03/12 08:24:11 q/of3Wvv
ext3で50GBとかのファイル数個をrmすると、50GBのファイル書くのと
同じくらい時間がかかるんだけどこれは仕様？
ディレクトリエントリ操作するだけなんだから一瞬で終わってしかるべきと
思うんだが・・・
844:login:Penguin
09/03/12 12:01:29 fUWg+Y+2
>>843
このスレで何度も話題になっているが、
なぜそうなっているのか技術的理由を書ける人が
このスレに現れたことはない。
845:login:Penguin
09/03/12 12:39:28 Gl1f5D2g
>>843
inodeを忘れないであげてください。
誰かがそのファイル掴んでいる状態で削除すれば、
ディレクトリエントリ消すだけなので一瞬で終わる。
んで、放した瞬間にHDDがカリカリ言い始めるはず。
ということでinode(つうかメタデータ)の更新がすげー遅い。
846:login:Penguin
09/03/12 13:30:20 FK4CPecw
そりゃbitmap使ってるfsの宿命ですがな。
つか、このスレの住人って読込み性能にあんまりフォーカスしてないのはなぜ？
847:login:Penguin
09/03/12 14:45:45 uwGP8iQx
読み込みは気になったこと無いなぁ。
848:login:Penguin
09/03/12 20:47:20 /5waLCXS
去年のカンファレンスでプレゼンターが削除速度を速くしたくて・・・と話していたら
Ted Tsoが割り込んでクラッシュ時の信頼性をあげるために、わざとそうしていて云々と自説を述べ始めて、
スピーカー困惑。
・・・かと、思ったらそこにさらにLinusが割り込んで、「ふざけるな。オレもふだんイライラしてるんだ。高速化しる！」とか自説を
述べ始めて、二人がプレゼンターそっちのけで議論をつづけるので、セッションにすごい微妙な空気が流れたことが
発表者の中の人がかわいそうすぎます
849:login:Penguin
09/03/12 21:06:32 Q9tPCjh3
何度も言うが
難しいことを考えずにXFSを使え
850:login:Penguin
09/03/12 21:15:11 8EggFbE/
さすがXFS教。言うことが違う。
851:login:Penguin
09/03/12 21:18:29 HGzIMQq7
ここは、btrfsに期待
852:login:Penguin
09/03/12 21:19:13 2VoPly+Y
結論 JFSでまた～り
853:login:Penguin
09/03/12 23:23:22 RqJ4/lD8
プレゼンターも、突っ込んでやれよ。
俺は、Linusにつくね。
クラッシュ時の信頼性って言えば許されるとおもってんのか！
だから、ZFSみたいなのが作れないんだよ、と。
854:login:Penguin
09/03/13 00:29:01 AmR0mtlJ
信頼性軽視するからLinuxのfsは他OSからportしてきたものでもアレなことに
なっているけどな。おまけに大して性能も出ていないし。
855:login:Penguin
09/03/13 00:46:56 Xd/smKgF
いろんなFSを量産しているのも弊害だよなぁ
856:login:Penguin
09/03/13 08:53:47 QyWnsw8e
>>854
信頼性重視なの？
857:login:Penguin
09/03/13 08:55:22 QyWnsw8e
ごめん。読み違えたw
そうだよなー。
重視してるならReiserの時もあそこまでフレームが大きくならなかっただろうし。
858:login:Penguin
09/03/13 20:05:10 DZg3JUvb
Solaris ZFSの基本的な仕組みを知る
URLﾘﾝｸ(www.atmarkit.co.jp)
859: ◆IIiDC8JS7w
09/03/13 21:14:51 dlpFGOyH
たくさんのファイルを複数のディレクトリに
ファイルを作成したり、削除したりする時間を測定する
ツールがあるので、使って性能測定してみてください。
redhatの人とか、btrfsの評価で使ってくれている。
URLﾘﾝｸ(www.spinics.net)
↑の最後のほうにコードが載ってます。
860:login:Penguin
09/03/13 23:39:08 x6C+8Djd
ext4がXFSライクなデータ消失を起こしたようです。
URLﾘﾝｸ(slashdot.jp)
861:login:Penguin
09/03/13 23:41:42 E6JaImFf
一緒にすんなハゲ
XFSでこんなこと起きねえよ
862:login:Penguin
09/03/13 23:43:52 JibFhBsj
>>861
最近クラッシュしたときに、書き込みしてなかったか？
ファイルサイズが同じでも中身が0で埋まってるファイルが
できてるかもよ。
rsyncでとってたバックアップも死んでるかもwwww
863:login:Penguin
09/03/14 07:11:48 cN9wHfAO
fsのバグでもなんでも無いじゃないか。
URLﾘﾝｸ(slashdot.jp)
864:login:Penguin
09/03/14 10:33:27 wTSiQHD4
>>859
ファイルシステムベンチマークなら、bonnie++が定番。
865:login:Penguin
09/03/14 10:46:54 Fjttua0k
これってext3でも起こるよね。起こりにくいだけで。
>>863の最初の例なんか、
truncate -> writeで、write前に落ちれば
どのジャーナルモードでもデータが消えるんじゃないか?
すでに実行されていたとしても、ジャーナルにあって次マウントしたときにreplayされても。
866:login:Penguin
09/03/14 11:40:29 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")
にすべきだよな
867:login:Penguin
09/03/14 14:45:40 NGZaZVb3
>>865
最初のはそうだけど、２つ目が問題なんだわ。
xfsはデフォルトでメタデータが先にコミットされるので、その直後に
クラッシュするとファイルシステムの構造的には不整合はないが、その
メタデータが指しているデータは存在しない。
で、xfsはメタデータがゴミデータを指してる状態で開けると、何が
見えるかわからん（古い/etc/passwdのブロックかもしれん）から
セキュリティ的な問題があるよね、ときちんとメタデータが指している
データを最初はゼロクリアした状態にしている（本来のデータがコミット
されたら当然そちらに付け替える）。
ext3等はデフォルトではデータが先にコミットされるので、２での問題は
生じ得ない。一方、xfsの順序は最高性能を発揮するためで、生まれた時代や
背景を考えると致し方ない。
POSIX的にはfsyncしてない限り、どちらの挙動も問題なしで、fsyncしない
アプリ開発者がPOSIXを理解してないというのが結論になる・・・が、
正直２の書き方って、すごい一般的だよね、さあどうしよう、という状況。
hogehoge > fugafuga && fsync fugafuga.new && mv fugafuga.new fugafuga
とか直していくしかない。Ubuntuだっけ？にfsyncコマンドがあるのは
このためだろうと思われる。
もっとも、ドライブキャッシュがあるとfsyncすら保証してくれないので、
さらにバリア張らないととか延々と話が続くんだけど。
868:login:Penguin
09/03/14 16:28:12 l9ZzVqeQ
blogの翻訳？
869:login:Penguin
09/03/14 19:12:33 ++9sa7SW
一時ファイルに書き込み→名前変更ってのは当たり前の技法だと思ってたけど
そうでもないのかな？
870:login:Penguin
09/03/14 20:08:40 6p4fiq3F
>>869
いや、あたりまえの技法というコンセンサスはとれていた。ゆえにTed Tsoは仕様どおりだ！とか片意地はらずに直すと言っている。という理解
871:login:Penguin
09/03/14 20:11:26 RgsfJUAA
しかしまぁ、仕様通りだから悪くない、と言っても汎用的なFSとしては使えないよなぁ
872:login:Penguin
09/03/14 20:19:32 qHb4tz1u
でもそうやって理想の仕様よりも現実を優先していくとWindowsみたいになるわけだけだが。
一見すると謎仕様すぎて、分かってない連中にボロくそに言われるという。
873:login:Penguin
09/03/14 20:21:09 Fjttua0k
>>867。
なるほど。
>>869もいってるけど、うまく書けたらリネームっていうのは、良くやるやり方なので、
確かにext3の挙動の方が安心できる気がしますね。
結局ext4での書き込みがext3より大幅に遅延するとしても、
ジャーナルに記録されていれば大丈夫な気がするのだが。
874:login:Penguin
09/03/14 20:23:23 2PA7Wxqo
そしてHans Reiser恩赦に
875:login:Penguin
09/03/14 21:23:11 Qv+bO9QY
壊れたメタデータのコミット先を教えるかわりに
FSの破壊を軽減する司法取引だな
876:login:Penguin
09/03/14 21:57:26 wTSiQHD4
ZFSとかFS層の破壊防止を徹底してるから、
これからはそういう設計が定番になるんじゃないかな。
Btrfsはどうなんだろ？
877:login:Penguin
09/03/14 23:59:37 1qF/srTZ
super_operations構造体のメンバ
freeze_fsやunfreeze_fsってwrite_super_lockfsやunlockfsから名前変えたのか？何故に・・
878:login:Penguin
09/03/15 10:02:11 PCGBiEcT
>>872
これは現場ではうまくいっていたけど理想的な方法ではないのを、改めているのだと思うぞ。
879:login:Penguin
09/03/15 10:18:44 xjkBDfQM
>>877
きまぐれ。
880:login:Penguin
09/03/15 19:42:41 PU06YtSt
もう名前変更しなくていいようにメンバは
struct struct0001_s {
member0001_t member0001;
member0002_t member0002;
member0003_t member0003;
...
として意味は仕様書と帳票で管理すべし。これならコードで
書く内容も迷うことが少なくていいし、順序がずれたらABI破壊バグと
すぐわかる。
881:login:Penguin
09/03/15 20:01:52 mnUY72EV
>>879
だったら やめて ちょうだい
本気で好きになりそうだから
あなたの前では きれいでいたいし
882:login:Penguin
09/03/15 20:31:39 ReDUN6Ol
>>876
btrfsはZFSと同じくCOWで書くから、この問題は起こらない
883:login:Penguin
09/03/15 20:34:14 kmO3PCzB
btrfsはなんでaddressingを128bitにしなかったの？ZFSに負けちゃうよ
884:login:Penguin
09/03/15 20:56:32 LgaDmqJ8
>>881
吹いた
885:login:Penguin
09/03/15 22:13:07 VfSmlfyi
デ♥フ♥ラ♥グ
886:login:Penguin
09/03/15 23:37:34 mnUY72EV
>>884
歌詞の一部です 若かった昔を思い出させる
今夜のナンバー １曲目は
長渕剛 素直
URLﾘﾝｸ(www.youtube.com)
887:login:Penguin
09/03/16 01:59:21 Gwa/wpQE
>>883
btr2fs誕生のフラグです
888:login:Penguin
09/03/16 02:03:51 08WqhxTZ
>>883
アドレスが128bitだとIPv6を連想して不吉だから
889:login:Penguin
09/03/16 15:19:00 fRtMFqd9
マジレスするとVFSが対応していない。
890:login:Penguin
09/03/16 15:31:04 FfCxFL0P
ext3は罪な奴だな
fsyncを徹底すると遅すぎて使い物にならないし
fsyncをしなくても十分安全だから
fsync無しの更新を一般化させてしまった
ext4も、data=orderedがデフォルトで安全なはずなんだけどなぁ
遅延アロケーションはジャーナルのコミットを考慮しない言うのか
891:login:Penguin
09/03/16 16:49:59 TUvh8KP2
extなんとかが最もポピュラーなのはなぜ？
歴史的な理由ですか？
892:login:Penguin
09/03/16 18:13:10 4dJsZZR0
なんだかんだで愛されてるんだよ
893:login:Penguin
09/03/16 18:59:45 XO5/u8kb
殺人よりはマシだからな（ワラ
894:login:Penguin
09/03/16 20:55:40 fRtMFqd9
>>891
そのとおり。
ext2時代は事実上、それしか選択肢がなかった。
ext3時代はredhatが他のFSをサポートしなかった。FSの品質はテスターの数にめっさ依存するので
ディストロの対応重要。