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

1 名前：login:Penguin mailto:sage [2007/09/26(水) 15:39:21 ID:VZk+Fjj0] 過去スレ 　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/ 232 名前：login:Penguin mailto:sage [2008/01/26(土) 07:10:51 ID:nkamkNao] それはジャーナル有る場合だろ 233 名前：login:Penguin mailto:sage [2008/01/26(土) 07:50:09 ID:8OpwyOTH] はあ？ 234 名前：login:Penguin mailto:sage [2008/01/26(土) 14:24:53 ID:nFnPAV3G] 同期・非同期とトランザクションの区別はつけようぜ。 235 名前：login:Penguin mailto:sage [2008/01/26(土) 15:24:51 ID:Pvih2f3X] >>232 fsckでなかったものにされるんじゃね？ ジャーナルなんて関係ないでしょ。 236 名前：login:Penguin mailto:sage [2008/01/26(土) 15:53:50 ID:8QyNar63] >>235 fsckすると残りのジャーナルを適用することもある。 どっちが整合性を保ちつつデータを保全できるかによるようだ。 237 名前：login:Penguin mailto:sage [2008/01/26(土) 17:14:55 ID:X0RlC9mR] ちょっとまて >>226の >フルデータジャーナリング使うぐらいなら同期マウントした方が良い かどうかだろ ジャーナリング無しで同期書き込みしたらfsckでロールバックかかるってこと？？ 238 名前：login:Penguin mailto:sage [2008/01/26(土) 17:25:57 ID:IqVOKU/f] ちゃんと流れ読めよ 239 名前：login:Penguin mailto:sage [2008/01/26(土) 19:00:37 ID:Pvih2f3X] >>236 なんでそうなるのか、それがわからん。 同期の場合は、sync（）にしろwrite（）にしろ、書き込みがすべて終わるまで戻ってこないんでしょ？ 対象がジャーナルFSであっても。 >>237 fsckで行う作業をロールバックというな。 240 名前：login:Penguin mailto:sage [2008/01/26(土) 21:51:13 ID:X0RlC9mR] 状況がよく分からんのだが、ファイルの内容書き換え中に落ちたとして、 fsckでどうやってロールバックされるわけ？ >>230な状況になるんじゃないのか 241 名前：login:Penguin mailto:sage [2008/01/27(日) 01:29:39 ID:LrB7nbuV] RDBMSの場合は、SQLレベルでの論理的な操作すべてが記録されているから、 直前のバックアップデータに対してログをリプレイすることで、完全復旧ができるというわけだが、 ファイルシステムに当てはめて考えれば、バイトレベルの操作すべてに対してログが採られていなければ、データの中身までは保障できないということになる。 現実的には、そんなことしてたらログの量がとてつもなくなるから、到底無理な話。 ジャーナルFSが復旧処理でやっていることは、通常のfsckがすべてのファイルに対して実行する検査を ログをなめることで省略しているにすぎない。 当然、正常に閉じていないファイルは、問答無用でlost+found逝きとなる。 これをロールバック/フォワードなどという言うには違和感あるでしょ？ 242 名前：login:Penguin mailto:sage [2008/01/27(日) 03:02:00 ID:i1WeOFxf] >>241 データについてもする場合はopen以後のwriteは別領域に書いて、 適当なタイミングでFS構造からの参照を付け替えればいいだけ。 この場合、write中にクラッシュした後の復旧でロールバックする。 ただし XFS とかの実装だとcreat自体はコミット済みだから ０バイトファイルが残ってくれたりとある意味困った挙動になったり。 さらに進んでNTFSとかreiser4ではアプリ側からトランザクション性を 制御した書き込みができる（た？）はずだけど、どういう形なんだっけ？ あとfsckがやってるのは正常に閉じられなかったファイルではなく、 参照があるのに参照先がないとか、参照がないのに実体があるとかの FS構造としての不整合状態をブロックをなめて発見したものを lost+foundに集めたりクリアしたりしてるだけで、閉じられなかった ファイルを救ってるわけではない。 243 名前：login:Penguin mailto:sage [2008/02/02(土) 17:24:24 ID:Sk+gOLYe] どこのスレが該当するかわからんがとりあえずここに。 mdadmでraid1構築、ocfs2にフォーマットしてマウントは問題ないんだが、 raid0とraid10で同じ事をやると失敗する。 (ひとまずローカルディスクで実験してます。最終的にはiSCSIを複数使ってやる予定) 以下マウント時のエラー ocfs2_hb_ctl: I/O error on channel while starting heartbeart mount.ocfs2: Error when attempting to run /sbin/ocfs2_hb_ctl: "Operation not permitted" /etc/init.d/o2cb statusすると確かにハートビートが動いてない。 んで手動でocfs2_hb_ctl -S -d /dev/md7(作ったRAIDデバイスがmd7)実行するも ocfs2_hb_ctl: I/O error on channel while starting heartbeart でダメ。 これはocfs2の仕様なんですかね？GFS2だとなんとかなる？ clvmで-iと-mのが可能性あったりするのかなあ、もうわけわからん 244 名前：login:Penguin [2008/02/06(水) 21:12:32 ID:xB+Vp2Cl] トーバルズ：OS XはVistaよりマシ、でもファイルシステムはゴミ japanese.engadget.com/2008/02/05/linus-os-x-vista/ ktkr 245 名前：login:Penguin mailto:sage [2008/02/06(水) 21:24:53 ID:xsQFoZY7] 誰か言ってやってくれ LinuxはServer2008よりマシ、でもファイルシステムはゴミ 246 名前：login:Penguin mailto:sage [2008/02/06(水) 21:35:04 ID:CEBTMN4n] >>245 いやそれは逆だろ。 ファイルシステムはマシだが・・・。 247 名前：login:Penguin mailto:sage [2008/02/06(水) 21:43:01 ID:bycraF9D] NTFSってどうなん？ 248 名前：login:Penguin mailto:sage [2008/02/06(水) 21:45:17 ID:AbBwRF41] ゴミ 249 名前：login:Penguin mailto:sage [2008/02/06(水) 21:45:58 ID:kmV4D3eE] 速度的に光るものはないが、耐久力はゾンビ級。 ext3なんかよりよっぽど優れたfsだと思うんだけどな… 250 名前：login:Penguin mailto:sage [2008/02/06(水) 21:59:15 ID:MW2Uiq4L] >>249 それ賛同 251 名前：login:Penguin mailto:sage [2008/02/07(木) 00:55:39 ID:Jh0j2rM7] リーナスってバカだな 252 名前：login:Penguin mailto:sage [2008/02/07(木) 03:33:18 ID:UdsqPHwZ] ntfsでファイルがぶっ飛んで破片も出てこないのはプログラムが悪いの？ 253 名前：login:Penguin mailto:sage [2008/02/07(木) 10:56:01 ID:NVBqFf6j] 俺なんかはntfsよりreiser・・・じゃなかった、xfsで何事も無かったように再起動できたことに驚愕したものだが。 ntfsだとどっか壊れるよなーという落とし方をしてしまった時のことだ。 まぁxfsはfsckしないからというのもあるだろうが。 254 名前：login:Penguin mailto:sage [2008/02/07(木) 11:16:04 ID:JbuBRM/5] >>253 どこかに0バイトのファイルが転がってるかもよ。 255 名前：login:Penguin mailto:sage [2008/02/07(木) 17:47:13 ID:nagQT8db] ちなみにどういう落とし方したの？ 256 名前：login:Penguin mailto:sage [2008/02/07(木) 18:16:17 ID:lsDyIYji] 酒を飲みつつ恋愛論を語った 257 名前：login:Penguin mailto:sage [2008/02/07(木) 18:26:42 ID:MhI2GJBO] たしかにntfsだとぶっ壊れそうだ。 あとできちんとf*ckしとけよ。 258 名前：login:Penguin mailto:sage [2008/02/08(金) 02:06:16 ID:5Qp7toYJ] いったいなんのスレだよw >>253 xfsはマウント時にfsckするんじゃなかったっけ？ 259 名前：login:Penguin mailto:sage [2008/02/08(金) 02:20:17 ID:SRnPVqDy] >>258 昔のxfs_fsck.c int main(int argc, char **argv) { return 0; } 今はshell scriptになったな。 260 名前：不明なデバイスさん [2008/02/08(金) 07:58:24 ID:YoHKP6tC] >>198 索引の更新日付は収容ファイルの更新で変更になる、 だから索引の更新日付をチェックして前回バックアップした日付以前なら その索引直下に収容のファイルは対象外にできる、 そうすれば処理時間は一桁以下にできるのでは。 261 名前： ◆YtPQzYyEH. [2008/02/08(金) 15:40:09 ID:C4+Xg+NF] 262 名前： ◆JuFLxjEbXg [2008/02/08(金) 15:42:03 ID:C4+Xg+NF] な 263 名前：login:Penguin mailto:sage [2008/02/08(金) 16:39:10 ID:lO2z0Hih] NTFS自体は機能とパフォーマンスを考えたら PC用のファイルシステムではトップクラスじゃねーかと思う 大元のHPFSが優れていたんだろうな しかしNTやVistaでさえその機能をきちんと使っていない点でクソ それとフラグメント化が激しすぎるのもクソ HFSは褒める部分を探すのに苦労して苦労して、それでも何も見つからないくらいにクソ さらにそれを告げると信者が火病起こしてわめきだすのがさらにウザくてクソ ext系は、とりあえず動きますよって段階では不満は無いんだが それ以上のものでもないし、お世辞にも優れた部分は見出せない 偉大なる平凡 xfsは、こんなもんタダで使わせてもらって本当にいいんスか？って感じだな jfsは知らん reiser fsはこれからどうなっちゃうの？って感じ 264 名前：login:Penguin mailto:sage [2008/02/08(金) 16:49:38 ID:B7rrj2AA] NTFSは異常終了無しで半年使って、chkdskかけたら数千ファイルのaclが吹っ飛んだことがorz FSが問題なのかどうか微妙なラインだが手痛かった。 xfsはcronでデフラグかけてるといい感じでうごいてる。 reiserは・・・ボリュームでかいとマウント時にものっそ時間かかるんだが・・・ 265 名前：login:Penguin mailto:sage [2008/02/08(金) 18:25:44 ID:WpMOTmXO] xfsは古いマシンで使うぶんには良いんだけどね。 新しいserverに入れる気はおきないな、mlみてたら怖くて。 266 名前：login:Penguin mailto:sage [2008/02/08(金) 18:42:58 ID:PGSC+VCd] >>264 それはどんなファイルシステムでも書き込んだ後1度も読み取りもしなかった領域が 不良セクタ化したらウンコーッ　って話だろ。 267 名前：login:Penguin mailto:sage [2008/02/08(金) 18:47:17 ID:oKxB/QKg] >>265 新しいマシンだと何か不具合出るの？ 最近のコードが安定してない、って話なら分かるけど。 268 名前：login:Penguin mailto:sage [2008/02/08(金) 22:53:36 ID:5Qp7toYJ] xfsはシュルシュル、reiserfsはヌルヌル。 性能いいのはreiserなんだろうけど、 xfsはそこそこ性能を発揮して低負荷。 >>259 あーあー、そうだったそうだった。 月イチxfs_check使ってるので忘れてたわ。 269 名前：login:Penguin mailto:sage [2008/02/09(土) 11:55:22 ID:I5g2yu0o] >>264 MSKB831374、831375、327009、873437とか該当してなかった？ 270 名前：login:Penguin mailto:sage [2008/02/09(土) 12:20:37 ID:woPPxICV] xfsはファイルの削除が遅い。カーネルツリー削除するのに時間がかかるよー。 271 名前：login:Penguin mailto:sage [2008/02/09(土) 13:11:25 ID:aL9fnslD] 削除なんてバックグラウンドでやらせときゃいいじゃん 272 名前：login:Penguin mailto:sage [2008/02/09(土) 13:18:17 ID:JxDwlQM6] >>266 いやRAIDだし不良セクタ関係ないw ハード障害に対するFSの耐久性の話ではない。 273 名前：login:Penguin mailto:sage [2008/02/10(日) 21:20:25 ID:zTNy08k4] 3wareのRAID板で1TB*3のRAID5を構築したのですが、 Linuxのファイルシステムとしてデータ領域に適しているのはどれになるんでしょうか？ CPUはGeodeNXのDualなのでパワーはあまりありません。メモリは2GB積んでます。 reiserfsとXFSとで検討の枠を絞ってしまっていいものか、 最近のトレンドが分からないのでご意見ください。 現状持ってる数年前のイメージでは以下の感じ。 XFS ○　ファイルシステムが大きくてもマウントが早い ○　あまり負荷がかからない ○　reiserfsより早い ×　ファイルの削除が遅い ×　fsckちゃんとしてるのかよく分からない・・・ reiserfs ○　ファイルシステムの縮小が唯一できる ×　ファイルシステムが大きくなるとマウントが遅い 最近はどうなんでしょうか？ 274 名前：login:Penguin mailto:sage [2008/02/10(日) 21:29:22 ID:GwVP/ZS2] >>273 個人で使うなら大して変わらないから好きなの使えば? 275 名前：login:Penguin mailto:sage [2008/02/10(日) 21:33:29 ID:BEDS9Otr] 個人で1TBx3か？すごいな 276 名前：login:Penguin mailto:sage [2008/02/10(日) 21:43:31 ID:GwVP/ZS2] >>275 1TB 2.5万だからちょっとしたおもちゃだろ？ 277 名前：login:Penguin mailto:sage [2008/02/10(日) 22:46:57 ID:41EqjFSS] 1Tx3が2.5万x3 ML115が1.5万 メモリ2Gを0.5万で追加したとしても 9.5万で2TなNASが用意できる時代ですぜ。 278 名前：login:Penguin mailto:sage [2008/02/10(日) 22:52:26 ID:kPqZgS0L] 知らない間にバカ安になってるな。 うちのノートPCのHDDも取りかえたい。 279 名前：login:Penguin mailto:sage [2008/02/10(日) 23:13:04 ID:jaGVAHE6] 1Tも入れるものが無い 280 名前：login:Penguin mailto:sage [2008/02/11(月) 00:55:40 ID:v/vK9WxC] >>273 どちらが良いとは言わない、だがこれだけは言わせてくれ。 ・xfs_repair ＆ xfs_check は、1TB につき 1GB のメモリが必要。 ・プロセス毎で使えるメモリ量は限られている。(特に32bitな環境では) ・メモリを増設しても、プロセス毎で使えるメモリ量は変わらない。 281 名前：login:Penguin mailto:sage [2008/02/11(月) 00:57:39 ID:NXuZoz9l] >>280 >・xfs_repair ＆ xfs_check は、1TB につき 1GB のメモリが必要。 すごくフラグメントしてたり、むちゃくちゃになってしまった時に 必要なだけで、普段はそんなに要らない。 もっともcheckやrepairが必要なときは、かなり終わってるけどな。 282 名前：login:Penguin mailto:sage [2008/02/11(月) 12:55:43 ID:hHXFn50e] >>281 > > xfs_repair ＆ xfs_check は、1TB につき 1GB のメモリが必要。 > すごくフラグメントしてたり、むちゃくちゃになってしまった時に > 必要なだけで、普段はそんなに要らない。 俺は、良く聞く4MB/i-nodeにつき128MB/RAMという、xfs_repairの昔からの定説から 1TBならi-nodeはおよそこれ位だから、RAMはだいたい1GB的な一般解を>>280は導いてきたと思ったんだが i-nodeの大きさだけじゃなく、フラグメントも関係あるのか？ 俺はツーリングとか、息子の運動会、家族旅行で流し撮りした映像の置き場や、編集用として WD7500AAKS×4を2410SAでRAID5運用していたわけだが、RAMは1GBしか積んでない 当然中身はGBオーバーの動画ファイル群のみ だが突然の電源断や、停電などで落ちた際にxfs_checkをかける時でも、これまで一度として メモリが足りなくなったりしたことはこれまでなかった 俺はこれをエクステントが効いている為に、i-nodeの大きさ自体はそれほど増えていないからだと 理解していた訳なんだが、もしフラグメントが関係しているなら、一度もxfs_fsrをかけたこともなく 使用量も80%を余裕で超えているこのディスクは、相当に断片化しているはずなんだけどな 283 名前：login:Penguin mailto:sage [2008/02/11(月) 13:01:33 ID:L4qR2Tu7] フラグメントは関係ない 284 名前：268 mailto:sage [2008/02/12(火) 02:16:28 ID:XWn0I4iF] >>280 システム移行時にサブ(メモリ256MBのP3)機で1.5TBのxfs_checkしたけど、 メモリ食う仕様忘れててswapディスクなしだと見事に固まったな。 低速ながらswapディスク付けたら一晩ちょいでどうにか終わってた。 285 名前：login:Penguin mailto:sage [2008/02/14(木) 10:51:10 ID:U8W3css3] ttp://www.smalltown.ne.jp/~usata/diary/?date=20080213#p01 おれもxfsってたまに重くなると思ってた。 こういうのもログを別ディスクにしたら性能あがるのかね 286 名前：login:Penguin mailto:sage [2008/02/14(木) 10:57:56 ID:S8QS6vkZ] >>285 swapに追い出せないジャーナル用のメモリを他のアプリや カーネルと取り合いしてメモリ上でスラッシングしている んじゃないかな。 287 名前：login:Penguin mailto:sage [2008/02/14(木) 10:59:02 ID:S8QS6vkZ] だから、高速なディスクに素早くジャーナルを書き出せれば 起きないのではないかと思う。 288 名前：login:Penguin [2008/02/16(土) 10:58:54 ID:1+pZMLPj] >>281 xfs_repair,xfs_checkは正常にマウントできなくなった時に使う。 １TB当たり1GBは正解。 ただし、今じゃxfs_repair -L位しか使った記憶ないなぁ 289 名前：login:Penguin mailto:sage [2008/02/21(木) 00:04:34 ID:Qe0QvPTZ] SuSEでブート領域を外部ディスクにして使ってます。 その外部ディスクが停止したりしてI/Oが一時的にでも停止すると、 ext3 が即座に Read-only で自動的にリマウントされます。 調べたところこれはext3(ext2)の仕様のようですが、どうにかして リブートせずに Read-write でリマウントできないでしょうか？ 今まで試したことは以下の通りです。 1. mount の remount オプションの使用 2. マウントしたまま fsck をかけた後、1を実施 tune2fs のエラー発生時のハンドリングは Continue になっています。 スレ違いでしたらすいません。 290 名前：login:Penguin mailto:sage [2008/03/02(日) 13:54:44 ID:hc9C85N7] 1FSあたりのファイル,ディレクトリ数って、増えすぎると速度落ちるよね？ その辺のデータって詳しいサイト無いかな。若しくは影響出やすいFSの体験談とか。 1ディレクトリに大量ファイルってのはまたちょっと別なんだけど。 291 名前：login:Penguin mailto:sage [2008/03/02(日) 13:57:47 ID:e0Thmhwp] それはフラグメンテーション 292 名前：login:Penguin mailto:sage [2008/03/02(日) 15:02:36 ID:hc9C85N7] あぁ、ファイルの読み取り速度とかディスク速度とかじゃなくて、 ファイルへのアクセス速度(fopen完了までとか)ね。 293 名前：login:Penguin mailto:sage [2008/03/02(日) 15:09:57 ID:e0Thmhwp] それもフラグメンテーション 294 名前：login:Penguin mailto:sage [2008/03/02(日) 21:13:23 ID:hc9C85N7] なんのこっちゃ・・・ えーとじゃあ、デフラグした状態で。 295 名前：login:Penguin mailto:sage [2008/03/02(日) 21:19:19 ID:1ooFJNDl] >影響出やすいFS FATとかか？ 296 名前：login:Penguin mailto:sage [2008/03/02(日) 22:01:33 ID:QO19JZJo] 実装を別にしてもあれが糞なのは疑いようがない 297 名前：login:Penguin mailto:sage [2008/03/02(日) 22:03:01 ID:88VAzaOv] 手軽さと互換性をちょっとは評価してもいいとは思うが 298 名前：login:Penguin mailto:sage [2008/03/03(月) 14:31:32 ID:olTABkIp] NTFSはドライブ内のファイル数が増えてくると急に遅くなる気はするな MFT周りなんだろうけどよくわからん FATは論外として、xfsもファイル数増えるとなんかもっさり。 reiserは結構耐える感じ？ まnotailとかのオプションにもよるだろが 299 名前：login:Penguin mailto:sage [2008/03/03(月) 15:01:41 ID:JCTvrwL7] 単純にindexが肥えていじるのに時間かかるようになるから。 ファイルシステムは大体そういうものだ。 reiserはそういう状況でもそれなりに動く様に設計されとる。 300 名前：login:Penguin mailto:sage [2008/03/03(月) 15:08:13 ID:8CT1QtMK] ここまで客観的な数値ゼロ 301 名前：login:Penguin mailto:sage [2008/03/03(月) 17:34:55 ID:QQPe3/34] >>290が体験談を望んでるから妥当な流れ 別に有ってもかわまんので書いてくれても良いよ>>300 302 名前：login:Penguin mailto:sage [2008/03/03(月) 19:17:19 ID:ic5kxWI3] xfsに変えたら彼女ができました！ 303 名前：login:Penguin mailto:sage [2008/03/03(月) 20:25:58 ID:i1bQg1Re] reiserfsに変えたら妻が失踪しました！ 304 名前：login:Penguin mailto:sage [2008/03/03(月) 20:59:30 ID:vUAhW00A] zfsはどうなんだろうね、ｌｉｎｕｘでも早いところつかえるようにならなかね 305 名前：login:Penguin mailto:sage [2008/03/03(月) 23:37:31 ID:aMHSs4ys] jfsに変えたらサーバが青いタワー型に！ 306 名前：login:Penguin mailto:sage [2008/03/04(火) 00:03:47 ID:MG8dmV58] >>305 逆だろ、それ。 307 名前：login:Penguin mailto:sage [2008/03/04(火) 00:40:55 ID:mPcUgsuW] >>303 そういや、あれってどうなったんだろ。 保釈されたんかな？殺人容疑だからありえないか。 308 名前：login:Penguin mailto:sage [2008/03/04(火) 13:36:55 ID:luMzogFa] Reiserfsってどの程度のファイル数耐えられる？ ext2みたく酷くはないと思うが怖くて使ってない 309 名前：login:Penguin mailto:sage [2008/03/04(火) 20:56:04 ID:2F2RseEP] inodeが動的にあれだからなあ。 結構いくと思うけど。 310 名前：login:Penguin mailto:sage [2008/03/04(火) 21:53:43 ID:kk4vfn0k] 参考までにどぞ。 TimeMachineに頼れない人のための完全バックアップ方法：日経パソコンオンライン pc.nikkeibp.co.jp/article/NPC/20080204/292912/ 311 名前：login:Penguin mailto:sage [2008/03/16(日) 21:01:35 ID:flqkXLd1] ディレクトリエントリつーの？findしたときに読まれるデータを、 優先的にキャッシュに残しとくFSとかオプションとか無いかね。 312 名前：login:Penguin mailto:sage [2008/03/17(月) 10:38:08 ID:4IyCtHoK] それは FS というか単にキャッシュのアルゴリズムでは? 313 名前：login:Penguin mailto:sage [2008/03/17(月) 12:26:47 ID:7b6j/OHS] キャッシュバッファのレイヤですな 314 名前：login:Penguin mailto:sage [2008/03/17(月) 14:54:29 ID:nm4uxoxm] 普通はページキャッシュかブロックバッファと言わないか？ キャッシュバッファだと馬から落馬みたいだ 315 名前：login:Penguin mailto:sage [2008/03/17(月) 15:22:06 ID:pTUBucW/] >>311 Linuxならディレクトリエントリキャッシュはあるけど。 316 名前：login:Penguin mailto:sage [2008/03/18(火) 01:32:40 ID:jCQs8JOZ] >>314 buffer cacheといいたかったんだろう。 317 名前：login:Penguin mailto:sage [2008/03/23(日) 15:41:33 ID:NvqLU+q0] >>316 しかしバッファキャッシュはfindの高速化になんの関係もないので本来の意図は i-cache, d-cacheではあるまいか？ 318 名前：login:Penguin mailto:sage [2008/03/23(日) 16:57:13 ID:4i3/VEiN] >>317 通常のファイルシステムでは、ファイル名ってのはdirectory fileに格納されているので、buffer cacheは関係なくはないんじゃね？ むしろdirectory entryのcacheはfindには関係なくないか？ inodeのcacheを使うかどうかもfindのオプションによると思う。 319 名前：login:Penguin mailto:sage [2008/03/24(月) 11:41:29 ID:xCc6BPh+] そのへんよくわからんな Linuxのディスク〜fs〜buffスレとか無いものか 320 名前：login:Penguin mailto:sage [2008/03/28(金) 22:28:36 ID:26zHaioF] UBI File System kerneltrap.org/Linux/UBI_File_System 321 名前：login:Penguin mailto:sage [2008/03/29(土) 21:41:44 ID:f/e2EUT3] >>320 JFFS2のスケーラビリティーが悪すぎたので１００倍程度では心元ない 322 名前：login:Penguin mailto:sage [2008/03/30(日) 04:13:47 ID:GQ0aE0r7] ext4dev は早く正式なext4にならないかな 323 名前：login:Penguin mailto:sage [2008/03/30(日) 11:01:12 ID:IoGJIZKZ] ext4絡みでVFS廻り、相当変わってる？ 324 名前：login:Penguin mailto:sage [2008/03/30(日) 12:32:47 ID:pKiGTBVm] >>323 変わってませんので安心してFUDをお続けください。 325 名前：login:Penguin mailto:sage [2008/03/30(日) 14:13:24 ID:o6yKIr3w] ext3はjbdが1スレッドしかいないおかげで、しばしばこいつがボトルネックになったけど、 ext4では改善されるんかね？ XFSみたくノード毎にほしいよね 326 名前：login:Penguin mailto:sage [2008/03/30(日) 15:22:11 ID:IoGJIZKZ] いや、最近のxfsのアホみたいな変更の量は、 VFSが変わったせいかと思ったんだが。そうじゃないのね。 327 名前：login:Penguin mailto:sage [2008/03/30(日) 20:33:55 ID:hAIGTsTG] >>326 どこも変わってないじゃん 328 名前：login:Penguin mailto:sage [2008/03/30(日) 22:09:21 ID:o6yKIr3w] XFSつながりで、話を脱線させると、最近David Chinnerの Per-superblock unused dentry LRU パッチを評価してるんだけど、 これ、いいな。 だいぶ速くなる 329 名前：login:Penguin mailto:sage [2008/04/02(水) 23:36:16 ID:miBB8ivN] raid0とXFS組み合わせたらext2の1/7ぐらいしか性能でなかった。 ﾎﾞｽｹﾃ･･･ チューニングパラメタとかあんの？ 330 名前：login:Penguin mailto:sage [2008/04/02(水) 23:45:20 ID:MwvMzT8M] >>329 何を書いたかによるんでねぇの 331 名前：login:Penguin mailto:sage [2008/04/02(水) 23:47:09 ID:miBB8ivN] >>330 dbenchでのスループット 332 名前：login:Penguin mailto:sage [2008/04/02(水) 23:53:19 ID:miBB8ivN] ちなみに本日の測定結果 ext2: 470MB/s ext3: 150MB/s XFS: 70MB/s

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef