- 1 名前：login:Penguin mailto:sage [2008/10/26(日) 15:18:36 ID:VYy55fXH]
- 過去スレ
01 pc.2ch.net/test/read.cgi/linux/1006743807/
02 pc5.2ch.net/test/read.cgi/linux/1063025258/
03 pc8.2ch.net/test/read.cgi/linux/1101495293/
04 pc8.2ch.net/test/read.cgi/linux/1136695633/
05 pc8.2ch.net/test/read.cgi/linux/1152348695/
06 pc11.2ch.net/test/read.cgi/linux/1173530292/
07
08 pc11.2ch.net/test/read.cgi/linux/1190788761/
- 816 名前：login:Penguin mailto:sage [2009/03/10(火) 20:09:03 ID:OxRS8Iom]
- お前んとこだけだよ
- 817 名前：login:Penguin mailto:sage [2009/03/10(火) 21:01:28 ID:yDC62HHM]
- >>816
んじゃ、HDDの初期不良かな
- 818 名前：login:Penguin mailto:sage [2009/03/11(水) 00:50:24 ID: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
- 819 名前：login:Penguin mailto:sage [2009/03/11(水) 00:51:59 ID:Q/Pii7+/]
- 三国志ヲタには馬騰fs
- 820 名前：login:Penguin mailto:sage [2009/03/11(水) 00:52:32 ID: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
- 821 名前：login:Penguin mailto:sage [2009/03/11(水) 00:54:35 ID: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
- 822 名前：login:Penguin mailto:sage [2009/03/11(水) 00:56:16 ID: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
- 823 名前：login:Penguin mailto:sage [2009/03/11(水) 00:57:37 ID:RdiNL0Kx]
- シングルタスクしかしない人ですか？
- 824 名前：login:Penguin mailto:sage [2009/03/11(水) 01:07:56 ID:Tlh+Q3Rr]
- どれを使っても大差ない感じなのかな。そうなるとシステム負荷が軽いのが良いな。
- 825 名前：login:Penguin mailto:sage [2009/03/11(水) 01:09:16 ID:oxPAi9BH]
- xfsは小ファイルの処理が非常に遅いと感じていたので、
HDDを買い足したついでにテストしてみた。
どのファイルシステムでも小ファイルの処理には
それなりに時間がかかるものなんだな。
(kernelとかだともっと差がつくようだが)
HDDのヘッドが退避しないうちにさっさとテストしたつもりだけど、
どこか手違いがあったのかもしれない。
あるいはWD10EADSが低速回転だから差がつかなかったのかな。
個人的なバックアップ用途としてはxfsも悪くないのかもしれない
- 826 名前：login:Penguin mailto:sage [2009/03/11(水) 01:38:14 ID:Tlh+Q3Rr]
- >>825
自分もxfsが細かいファイルにもっと時間が掛かると思ってたw
ちなみに使用しているカーネルのバージョンは?比較的最近のカーネルかな。
- 827 名前：login:Penguin mailto:sage [2009/03/11(水) 04:29:15 ID:KO510Owq]
- >>823
どんな形であれ、せっかくテストしてくれているんだから、そんな言い方をしたら失礼だぜ？
- 828 名前：login:Penguin mailto:sage [2009/03/11(水) 05:15:14 ID:Oxh4Vyl/]
- >>825
$ tar tjf MPlayer-1.0rc2.tar.bz2 |wc -l
3260
もう一桁多いのを試してほしいような…
つうか一個のディレクトリに大量に置かないと有意な差は見えないと思う。
- 829 名前：login:Penguin mailto:sage [2009/03/11(水) 08:03:47 ID:4YDbCnMJ]
- XFSはあらゆる場面において
最も速く、最も安全に使えるファイルシステムです
- 830 名前：login:Penguin mailto:sage [2009/03/11(水) 08:55:12 ID:hFe1ZwTZ]
- 釣るつもりならもっと上手く書けボケ老人
- 831 名前：login:Penguin mailto:sage [2009/03/11(水) 10:59:47 ID:4YDbCnMJ]
- 釣りではありません
真実を述べているだけです
- 832 名前：login:Penguin mailto:sage [2009/03/11(水) 11:10:01 ID:rfDVx5RA]
- >>831
では適切な検証をデータ込で提示してくださいな
スレ住民も条件の選び方から見て自分にあったFSか見極めるでしょうから
「そんなことしなくても自明です」なんて言ったら電波確定
- 833 名前：login:Penguin mailto:sage [2009/03/11(水) 11:58:04 ID:4YDbCnMJ]
- 何をやってもXFS批判を噴出させるのが
このスレの住人というものです
- 834 名前：login:Penguin mailto:sage [2009/03/11(水) 12:36:41 ID:EgNJdZ2x]
- 普段使うだけならjfs悪くないよ。
xfsはgentooでいろいろでかいのビルドするとき遅いと感じる。
- 835 名前：login:Penguin mailto:sage [2009/03/11(水) 12:47:07 ID:KEpL3SfB]
- >>825
単一ディレクトリに多数の小ファイルがある場合XFSは速いけど
多数のディレクトリに分散してそれぞれ100個程度の小ファイルがある場合は遅い
後者の場合だとext4のほうが速かった
>>834が遅いって言ってるのも、これだと思う
- 836 名前：login:Penguin mailto:sage [2009/03/11(水) 18:58:29 ID:VdtLCfNF]
- 家庭内的にjfs使い始めてそろそろ2年だが問題ないなぁ。
Maildirのメールサーバだから細かいファイルが沢山できる感じだが
特に問題がおきたことはない。
(スパムを全部取っているから数は結構あるな・・・)
引っ越ししたあと、家電が増えてブレーカー落ちやすくなったんだが
バカスカ落としても何もなかったように起動してくる。
偉いぜjfs。
というわけでもっとでかい運用状況聞きたいぜ。
- 837 名前：login:Penguin mailto:sage [2009/03/11(水) 21:17:13 ID: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しか使っていないから他は追試出来ないけど、どうせ他のテスト結果もウソっぱちだろう
- 838 名前：login:Penguin mailto:sage [2009/03/11(水) 23:12:10 ID:rkEwTD3M]
- z/Linuxに向いてるのは
どのファイルシステムですか？
- 839 名前：login:Penguin mailto:sage [2009/03/11(水) 23:42:26 ID:IrA1hiXP]
- >>836
そろそろクラッシュする頃だな
- 840 名前：login:Penguin [2009/03/12(木) 00:12:25 ID:QKWWjyLf]
- >>836
大規模システムで使っているＹＯ
小さいファイルが多いなら、おぬぬめ
- 841 名前：login:Penguin mailto:sage [2009/03/12(木) 05:39:50 ID: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 mailto:sage [2009/03/12(木) 05:59:17 ID: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 mailto:sage [2009/03/12(木) 08:24:11 ID:q/of3Wvv]
- ext3で50GBとかのファイル数個をrmすると、50GBのファイル書くのと
同じくらい時間がかかるんだけどこれは仕様？
ディレクトリエントリ操作するだけなんだから一瞬で終わってしかるべきと
思うんだが・・・
- 844 名前：login:Penguin mailto:sage [2009/03/12(木) 12:01:29 ID:fUWg+Y+2]
- >>843
このスレで何度も話題になっているが、
なぜそうなっているのか技術的理由を書ける人が
このスレに現れたことはない。
- 845 名前：login:Penguin mailto:sage [2009/03/12(木) 12:39:28 ID:Gl1f5D2g]
- >>843
inodeを忘れないであげてください。
誰かがそのファイル掴んでいる状態で削除すれば、
ディレクトリエントリ消すだけなので一瞬で終わる。
んで、放した瞬間にHDDがカリカリ言い始めるはず。
ということでinode(つうかメタデータ)の更新がすげー遅い。
- 846 名前：login:Penguin [2009/03/12(木) 13:30:20 ID:FK4CPecw]
- そりゃbitmap使ってるfsの宿命ですがな。
つか、このスレの住人って読込み性能にあんまりフォーカスしてないのはなぜ？
- 847 名前：login:Penguin mailto:sage [2009/03/12(木) 14:45:45 ID:uwGP8iQx]
- 読み込みは気になったこと無いなぁ。
- 848 名前：login:Penguin mailto:sage [2009/03/12(木) 20:47:20 ID:/5waLCXS]
- 去年のカンファレンスでプレゼンターが削除速度を速くしたくて・・・と話していたら
Ted Tsoが割り込んでクラッシュ時の信頼性をあげるために、わざとそうしていて云々と自説を述べ始めて、
スピーカー困惑。
・・・かと、思ったらそこにさらにLinusが割り込んで、「ふざけるな。オレもふだんイライラしてるんだ。高速化しる！」とか自説を
述べ始めて、二人がプレゼンターそっちのけで議論をつづけるので、セッションにすごい微妙な空気が流れたことが
発表者の中の人がかわいそうすぎます
- 849 名前：login:Penguin mailto:sage [2009/03/12(木) 21:06:32 ID:Q9tPCjh3]
- 何度も言うが
難しいことを考えずにXFSを使え
- 850 名前：login:Penguin mailto:sage [2009/03/12(木) 21:15:11 ID:8EggFbE/]
- さすがXFS教。言うことが違う。
- 851 名前：login:Penguin mailto:sage [2009/03/12(木) 21:18:29 ID:HGzIMQq7]
- ここは、btrfsに期待
- 852 名前：login:Penguin [2009/03/12(木) 21:19:13 ID:2VoPly+Y]
- 結論 JFSでまた〜り
- 853 名前：login:Penguin mailto:sage [2009/03/12(木) 23:23:22 ID:RqJ4/lD8]
- プレゼンターも、突っ込んでやれよ。
俺は、Linusにつくね。
クラッシュ時の信頼性って言えば許されるとおもってんのか！
だから、ZFSみたいなのが作れないんだよ、と。
- 854 名前：login:Penguin mailto:sage [2009/03/13(金) 00:29:01 ID:AmR0mtlJ]
- 信頼性軽視するからLinuxのfsは他OSからportしてきたものでもアレなことに
なっているけどな。おまけに大して性能も出ていないし。
- 855 名前：login:Penguin mailto:sage [2009/03/13(金) 00:46:56 ID:Xd/smKgF]
- いろんなFSを量産しているのも弊害だよなぁ
- 856 名前：login:Penguin mailto:sage [2009/03/13(金) 08:53:47 ID:QyWnsw8e]
- >>854
信頼性重視なの？
- 857 名前：login:Penguin mailto:sage [2009/03/13(金) 08:55:22 ID:QyWnsw8e]
- ごめん。読み違えたw
そうだよなー。
重視してるならReiserの時もあそこまでフレームが大きくならなかっただろうし。
- 858 名前：login:Penguin [2009/03/13(金) 20:05:10 ID:DZg3JUvb]
- Solaris ZFSの基本的な仕組みを知る
ttp://www.atmarkit.co.jp/fserver/articles/zfs/01/01.html
- 859 名前： ◆IIiDC8JS7w [2009/03/13(金) 21:14:51 ID:dlpFGOyH]
- たくさんのファイルを複数のディレクトリに
ファイルを作成したり、削除したりする時間を測定する
ツールがあるので、使って性能測定してみてください。
redhatの人とか、btrfsの評価で使ってくれている。
ttp://www.spinics.net/lists/linux-btrfs/msg02003.html
↑の最後のほうにコードが載ってます。
- 860 名前：login:Penguin mailto:sage [2009/03/13(金) 23:39:08 ID:x6C+8Djd]
- ext4がXFSライクなデータ消失を起こしたようです。
ttp://slashdot.jp/hardware/article.pl?sid=09/03/13/1311252
- 861 名前：login:Penguin mailto:sage [2009/03/13(金) 23:41:42 ID:E6JaImFf]
- 一緒にすんなハゲ
XFSでこんなこと起きねえよ
- 862 名前：login:Penguin mailto:sage [2009/03/13(金) 23:43:52 ID:JibFhBsj]
- >>861
最近クラッシュしたときに、書き込みしてなかったか？
ファイルサイズが同じでも中身が0で埋まってるファイルが
できてるかもよ。
rsyncでとってたバックアップも死んでるかもwwww
- 863 名前：login:Penguin mailto:sage [2009/03/14(土) 07:11:48 ID:cN9wHfAO]
- fsのバグでもなんでも無いじゃないか。
slashdot.jp/hardware/comments.pl?sid=442678&cid=1530766
- 864 名前：login:Penguin mailto:sage [2009/03/14(土) 10:33:27 ID:wTSiQHD4]
- >>859
ファイルシステムベンチマークなら、bonnie++が定番。
- 865 名前：login:Penguin mailto:sage [2009/03/14(土) 10:46:54 ID:Fjttua0k]
- これってext3でも起こるよね。起こりにくいだけで。
>>863の最初の例なんか、
truncate -> writeで、write前に落ちれば
どのジャーナルモードでもデータが消えるんじゃないか?
すでに実行されていたとしても、ジャーナルにあって次マウントしたときにreplayされても。
- 866 名前：login:Penguin mailto:sage [2009/03/14(土) 11:40:29 ID: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 mailto:sage [2009/03/14(土) 14:45:40 ID: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 mailto:sage [2009/03/14(土) 16:28:12 ID:l9ZzVqeQ]
- blogの翻訳？
- 869 名前：login:Penguin mailto:sage [2009/03/14(土) 19:12:33 ID:++9sa7SW]
- 一時ファイルに書き込み→名前変更ってのは当たり前の技法だと思ってたけど
そうでもないのかな？
- 870 名前：login:Penguin mailto:sage [2009/03/14(土) 20:08:40 ID:6p4fiq3F]
- >>869
いや、あたりまえの技法というコンセンサスはとれていた。ゆえにTed Tsoは仕様どおりだ！とか片意地はらずに直すと言っている。という理解
- 871 名前：login:Penguin mailto:sage [2009/03/14(土) 20:11:26 ID:RgsfJUAA]
- しかしまぁ、仕様通りだから悪くない、と言っても汎用的なFSとしては使えないよなぁ
- 872 名前：login:Penguin mailto:sage [2009/03/14(土) 20:19:32 ID:qHb4tz1u]
- でもそうやって理想の仕様よりも現実を優先していくとWindowsみたいになるわけだけだが。
一見すると謎仕様すぎて、分かってない連中にボロくそに言われるという。
- 873 名前：login:Penguin mailto:sage [2009/03/14(土) 20:21:09 ID:Fjttua0k]
- >>867。
なるほど。
>>869もいってるけど、うまく書けたらリネームっていうのは、良くやるやり方なので、
確かにext3の挙動の方が安心できる気がしますね。
結局ext4での書き込みがext3より大幅に遅延するとしても、
ジャーナルに記録されていれば大丈夫な気がするのだが。
- 874 名前：login:Penguin mailto:sage [2009/03/14(土) 20:23:23 ID:2PA7Wxqo]
- そしてHans Reiser恩赦に
- 875 名前：login:Penguin mailto:sage [2009/03/14(土) 21:23:11 ID:Qv+bO9QY]
- 壊れたメタデータのコミット先を教えるかわりに
FSの破壊を軽減する司法取引だな
- 876 名前：login:Penguin mailto:sage [2009/03/14(土) 21:57:26 ID:wTSiQHD4]
- ZFSとかFS層の破壊防止を徹底してるから、
これからはそういう設計が定番になるんじゃないかな。
Btrfsはどうなんだろ？
- 877 名前：login:Penguin mailto:sage [2009/03/14(土) 23:59:37 ID:1qF/srTZ]
- super_operations構造体のメンバ
freeze_fsやunfreeze_fsってwrite_super_lockfsやunlockfsから名前変えたのか？何故に・・
- 878 名前：login:Penguin mailto:sage [2009/03/15(日) 10:02:11 ID:PCGBiEcT]
- >>872
これは現場ではうまくいっていたけど理想的な方法ではないのを、改めているのだと思うぞ。
- 879 名前：login:Penguin mailto:sage [2009/03/15(日) 10:18:44 ID:xjkBDfQM]
- >>877
きまぐれ。
- 880 名前：login:Penguin mailto:sage [2009/03/15(日) 19:42:41 ID:PU06YtSt]
- もう名前変更しなくていいようにメンバは
struct struct0001_s {
member0001_t member0001;
member0002_t member0002;
member0003_t member0003;
...
として意味は仕様書と帳票で管理すべし。これならコードで
書く内容も迷うことが少なくていいし、順序がずれたらABI破壊バグと
すぐわかる。
- 881 名前：login:Penguin mailto:sage [2009/03/15(日) 20:01:52 ID:mnUY72EV]
- >>879
だったら やめて ちょうだい
本気で好きになりそうだから
あなたの前では きれいでいたいし
- 882 名前：login:Penguin mailto:sage [2009/03/15(日) 20:31:39 ID:ReDUN6Ol]
- >>876
btrfsはZFSと同じくCOWで書くから、この問題は起こらない
- 883 名前：login:Penguin mailto:sage [2009/03/15(日) 20:34:14 ID:kmO3PCzB]
- btrfsはなんでaddressingを128bitにしなかったの？ZFSに負けちゃうよ
- 884 名前：login:Penguin mailto:sage [2009/03/15(日) 20:56:32 ID:LgaDmqJ8]
- >>881
吹いた
- 885 名前：login:Penguin mailto:sage [2009/03/15(日) 22:13:07 ID:VfSmlfyi]
- デ♥フ♥ラ♥グ
- 886 名前：login:Penguin mailto:sage [2009/03/15(日) 23:37:34 ID:mnUY72EV]
- >>884
歌詞の一部です 若かった昔を思い出させる
今夜のナンバー １曲目は
長渕剛 素直
ttp://www.youtube.com/watch?v=cM-QvJI_RJQ
- 887 名前：login:Penguin mailto:sage [2009/03/16(月) 01:59:21 ID:Gwa/wpQE]
- >>883
btr2fs誕生のフラグです
- 888 名前：login:Penguin mailto:sage [2009/03/16(月) 02:03:51 ID:08WqhxTZ]
- >>883
アドレスが128bitだとIPv6を連想して不吉だから
- 889 名前：login:Penguin mailto:sage [2009/03/16(月) 15:19:00 ID:fRtMFqd9]
- マジレスするとVFSが対応していない。
- 890 名前：login:Penguin mailto:sage [2009/03/16(月) 15:31:04 ID:FfCxFL0P]
- ext3は罪な奴だな
fsyncを徹底すると遅すぎて使い物にならないし
fsyncをしなくても十分安全だから
fsync無しの更新を一般化させてしまった
ext4も、data=orderedがデフォルトで安全なはずなんだけどなぁ
遅延アロケーションはジャーナルのコミットを考慮しない言うのか
- 891 名前：login:Penguin mailto:sage [2009/03/16(月) 16:49:59 ID:TUvh8KP2]
- extなんとかが最もポピュラーなのはなぜ？
歴史的な理由ですか？
- 892 名前：login:Penguin mailto:sage [2009/03/16(月) 18:13:10 ID:4dJsZZR0]
- なんだかんだで愛されてるんだよ
- 893 名前：login:Penguin [2009/03/16(月) 18:59:45 ID:XO5/u8kb]
- 殺人よりはマシだからな（ワラ
- 894 名前：login:Penguin mailto:sage [2009/03/16(月) 20:55:40 ID:fRtMFqd9]
- >>891
そのとおり。
ext2時代は事実上、それしか選択肢がなかった。
ext3時代はredhatが他のFSをサポートしなかった。FSの品質はテスターの数にめっさ依存するので
ディストロの対応重要。
|
 |
