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

1 名前：login:Penguin [03/09/08 21:47 ID:YkHkXm1o] 多種多様なファイルシステムに対応しているLinux。 そのファイルシステムに関するトラブル、チューニング、愚痴^H^H感想などなど。 なんでも語ってくれ。 前スレ pc.2ch.net/test/read.cgi/linux/1006743807/ 496 名前：login:Penguin mailto:sage [04/05/20 14:21 ID:pv2juzoW] ファイルオープン数はとりあえず、 ttp://www.nxhack.tarumi.kobe.jp/linux_kernel_tuning.html を見てみれ。 inode数はman mkfs.ext2とかman mkfs.ext3したら -i bytes-per-inode この値は、一般にはファイルシステムのブロックサイズより小さくすべきではない。さもないと不必要に多くの inode が作られてしまう。 とか書いてある。 ディスクデバイスはブロックサイズ単位で読み書きするので、基本的には、1個のinodeはブロックサイズ分ディスクを使うと考えてくれ。 bytes-per-inodeをブロックサイズより小さくする ↓ パーティションを分割する単位データが小さくなる ↓ 通し番号として使うinodeの数が超増える ↓ 単位データが小さくなってもinodeはブロックサイズ分使ってて小さくならない ↓ ディスクの半分がinodeで使われる ↓ マズー まぁこうならないようにハイテクなファイルシステムではinodeのわりあてをいじるわけだがext3の理解だったらこんなもんでいいだろ。 497 名前：login:Penguin mailto:sage [04/05/20 14:41 ID:pv2juzoW] $ find e2fsprogs-1.35 -type f | xargs fgrep ext2_ino_t | fgrep typedef e2fsprogs-1.35/lib/ext2fs/ext2fs.h:typedef __u32 ext2_ino_t; 498 名前：login:Penguin mailto:sage [04/05/20 15:01 ID:tIP8zoBV] 497はext2ファイルシステムだと32ビット個のinodeしか作れないぞといいたいのだろうか 499 名前：login:Penguin [04/05/21 09:19 ID:kYzTzX93] なんか危険なことが起きてますね… On 2.6.0-testx kernels, I have noticed that there are problems with GNU Parted. Parted says that the disk geometries reported by the kernel are incorrect. /.J にもタレコみがありましたが。 500 名前：login:Penguin [04/05/21 11:23 ID:FV96uEsa] NFS の質問も良いでつか？　OS は Fedora Core 2 なんですが、 サーバは下記の通りです。 /etc/fstab:　LABEL=/home　/home　ext3　defaults,usrquota　1　2 /etc/exports:　/home　*　(rw,no_root_squash) クライアントは、 /etc/fstab:　sv:/home　/home　nfs　nfsvers=3,hard,intr,user,rw　0　0 となってます。 この設定で mount /home で普通にマウントできるのですけど、書き込みが できません。Permission denied だそうです。FreeBSD からもマウントを 試してみたのですが Read-only file system で、ほぼ同じです。当然ながら ディレクトリそのものには書き込み権限あります。なんででしょう？ 501 名前：login:Penguin mailto:sage [04/05/21 11:30 ID:kYzTzX93] >>500 もしかして両者のuid/gidが合ってないとか。 502 名前：500 mailto:sage [04/05/21 11:40 ID:FV96uEsa] >>501 さっそくありがとうございます。root でも一般ユーザでもダメです……。 権限の問題というよりも、マウントオプションで何かを忘れているために Read-only file system なんじゃないかと思ってます。うーむ。 503 名前：500 mailto:sage [04/05/21 14:11 ID:FV96uEsa] exports の微妙なスペースの差でダメだったみたいです。できました。 504 名前：login:Penguin mailto:sage [04/05/21 14:13 ID:VsRi3rpS] >>500 そうだそうだ。許可ホストとかっこオプションのところはくっつけないかんね。 505 名前：login:Penguin mailto:sage [04/05/24 10:25 ID:4ImjrC6R] ソフトウェアRAIDでRAID5のボリュームに既存のデータを壊さずに ディスクを追加できるのってraidreconfがあるLinuxだけ？ vinumやraidframeではどうなのかな。 506 名前：login:Penguin [04/05/26 00:13 ID:SfaM/mSu] あ？ 507 名前：login:Penguin mailto:sage [04/05/26 15:12 ID:pOHK88eZ] Linux-NTFS Projectの中の人も大変だな 508 名前：login:Penguin [04/05/26 22:05 ID:kckN2mm9] / を reiserfs にしてるんだけど、 その / をリードオンリーでマウントしてるのに mount コマンドでは /dev/hda2 on / type reiserfs (rw) とかってあたかもリードライト可能なように表示される。 他のファイルシステムでもそんな人いる？ 509 名前：login:Penguin mailto:sage [04/05/27 03:00 ID:Z984zvO6] 多分、readonlyであっても最初のmount時にjournalを強制的に反映させるために read-writeにしてるんじゃないですかね。 ext3もjfsもxfsもデフォルトはそうだと思う。 jfsはnointegrity optionで、xfsはnorecovery optionで mount時にjournalがどうなってようがreplayせずに放置してくれるそうだけど、 journalingのためのkernel daemonが動いたらrwにしてしまいそうな気もする。 ext3の場合はfilesystemをext2だと宣言してmountするのが安全かなぁ。 510 名前：login:Penguin [04/06/01 01:23 ID:tlN9OZLB] >>496 >ディスクデバイスはブロックサイズ単位で読み書きするので、基本的には、1個のinodeはブロックサイズ分ディスクを使うと考えてくれ。 ちょいと、ダウトしとこかな。 mkfs -i で指定するサイズの意味は、ファイルシステムを、その指定サイズのファイルで 埋め尽くしたときに、ちょうど足りるだけの inode 領域を作りますって意味に、100カノッサ。 あと、1 inode のサイズは、ext系だと多分128byte。 511 名前：login:Penguin mailto:sage [04/06/01 01:26 ID:nbK3Ai7O] reiser4はどうなったのか 512 名前：login:Penguin [04/06/01 19:53 ID:LxD/3eE0] debianをインストールするときにrescue.binは正常に通って 次にroot.binを入れてエンターを押すと ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ request_module[block-major-2]:Root fs not mounted UFS:Cannot open root device 02:00 Kernel panic: VFS: Unable to mount root fs on 02:00 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ と出てしまいインストールをすすめる事が出来ません、、 何が原因でしょうか？ ご教授してください。 お願いいたします。 ちなみにDebian GNU/Linux 3.0(woody) をインストール中です。 513 名前：login:Penguin mailto:sage [04/06/01 20:32 ID:K0TAxYKz] >>512 Debianスレにいった方がいいと思うが… 単にfloppyが壊れているんじゃないの? 514 名前：login:Penguin mailto:sage [04/06/02 11:06 ID:Ci6HeraW] >>512 pc5.2ch.net/test/read.cgi/linux/1085817615/135 515 名前：login:Penguin mailto:sage [04/06/05 00:05 ID:B7RiJ4DO] cfs使ってみたいんですけどその話題もここでOK？ 516 名前：login:Penguin [04/06/06 16:11 ID:1wMuQIJs] 0k 517 名前：login:Penguin mailto:sage [04/06/12 02:58 ID:0LhZcALe] ext3が壊れたのですが、これって何が起こったのですか？ 発生状況としては、hibernateを繰り返しながら使っていたノートPCを、 デュアルブートのWindowsに切り替えるため再起動。 Windowsでの作業(linuxパーティションへのアクセスは無し)を終え、 Linuxを起動するとなぜかrpmのDBが壊れてる。 rpm --rebuilddb で修復すると、一部パッケージ情報が欠落。 何となく(すみません、何でだったかな)再起動すると、/ の ファイルシステムチェックが動き、さらにrootのパスワードをいれて、 fsckしろと。したら一部ファイルが/lost+found逝きに。 ま、こういう時に再インストールに逃げやすいよう、/home を別パーティションに 分けてあるので再インストールのつもりなんですが、原因は何でしょうね？ ・ハードウェア異常でHDDが壊れた（でも、smartctl によれば異常無し） ・ドライバのバグ、configミス(でも、結構長く使ってる2.4系カーネル。自家ビルド) ・その他 消去法でもいいんで、何かあったらよろしくです。 ちなみにディストリビューションはVineLinux(Seed)です。 518 名前：468 [04/06/12 05:55 ID:dPI2DSbQ] >>517 壊れる前の数日とか、ログに何も出てなかった？ 519 名前：login:Penguin mailto:sage [04/06/12 15:11 ID:0LhZcALe] >518 grep -e '\(ext3\|hda\)' /var/log/* で調べましたけど、正常なログと壊れたときのfsckの時のログしか出てきませんでした。 (ログが壊れてる様子は無いですね) fsckのログは以下。最初のタイムスタンプがずれてるのはキーボード入力を放置したからかな？ ジャーナリング最強、壊れるわけねーぜと思い込んで真面目に作業してなかった・・・。 Jun 11 16:30:10 localhost kernel: EXT3-fs error (device ide0(3,5)): ext3_readdir: bad entry in directory #644496: rec_len is smaller than minimal - offset=96, inode=646822, rec_len=0, name_len=0 Jun 11 16:59:54 localhost kernel: EXT3-fs error (device ide0(3,5)): ext3_readdir: bad entry in directory #599176: directory entry across blocks - offset=0, inode=599176, rec_len=9352, name_len=9 Jun 11 17:00:09 localhost kernel: EXT3-fs error (device ide0(3,5)): ext3_readdir: bad entry in directory #470676: directory entry across blocks - offset=0, inode=470676, rec_len=11924, name_len=7 Jun 11 17:00:24 localhost kernel: EXT3-fs error (device ide0(3,5)): ext3_readdir: directory #82031 contains a hole at offset 0 Jun 11 17:00:24 localhost kernel: EXT3-fs error (device ide0(3,5)): ext3_readdir: directory #82031 contains a hole at offset 4096 (中略、前後の行とdirectory #とoffsetだけが違うのが15行ほど) Jun 11 17:00:34 localhost kernel: EXT3-fs error (device ide0(3,5)): ext3_readdir: directory #82019 contains a hole at offset 16384 Jun 11 17:00:56 localhost kernel: EXT3-fs error (device ide0(3,5)): ext3_readdir: bad entry in directory #644496: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0 520 名前：login:Penguin mailto:sage [04/06/13 06:47 ID:B8KhNcsS] 正直、NTFSは無駄多いしそんなに速くないけど偉大だとつくづく思わされた…ﾊｧ 521 名前：468 [04/06/13 07:44 ID:rXdYP9Bk] >>519 おお、俺の(468)と同じじゃないか。 これ fsck のログじゃなくて、普通のディスクアクセス時のログでしょ。 fsckが何かログを吐くのかは知らないけど、fsckするときはアンマウントしてるはずだから EXT3-fs errorってことにはならないような。 522 名前：login:Penguin mailto:sage [04/06/13 10:03 ID:BIfDG3Tz] >>519 ハイバネってAPMハイバネ?swsusp? 使ってるカーネルが明記してないあたりから察して いろんなパッチあててるんじゃないか? 523 名前：login:Penguin mailto:sage [04/06/13 10:29 ID:Xw8IMvv9] 昔、LBAでdisk使っているのに、 Windows+BIOSのハイバネはCHSだと思ってて、 Linuxのpartition壊されたことあったな。 まあ、最近はLBAばっかりだとは思うが。 524 名前：login:Penguin mailto:sage [04/06/13 14:32 ID:bthVhoxo] >>521 あ、そうなんですか？ その時間帯fsckしてたような気がするんですけど、そういわれてみればそうかも。 >>522 ハイバネは 2.0.0.44 です。 カーネルは自家ビルドと思っていましたが今調べたら Vine 製(kernel-2.4.26-0vl1)でした。 e2fsprogsのバージョンはfsck.ext3 -Vで調べたら1.35(28-Feb-2004)でした。 >>523 Windows+BIOSのハイバネって、下記URLの ＞ノートPCのハイバネーション機能はノートPCのハードベンダーが独自に組み込んだもので、OSが用意した機能ではない。 の奴ですか？ ttp://nobumasa-web.hp.infoseek.co.jp/multi_boot/etc.html#hibr うちのWindowsで使ってるのはWindows2000自体の機能の休止状態です。 しかし、ブートセクタやMBRが侵蝕されたならともかく、ファイルシステムの 一部が壊れたわけですから、関係ないと決めつけてるんですがどうでしょうか。 525 名前：login:Penguin mailto:sage [04/06/13 16:32 ID:2N27U/2Y] >>520 >正直、NTFSは無駄多いしそんなに速くないけど偉大だとつくづく思わされた…ﾊｧ またまた冗談を。なんかNTFS信者って多いな。 NTFS信者=Win信者？ 526 名前：login:Penguin mailto:sage [04/06/13 16:57 ID:08tOn3UP] 透過圧縮とか謳い文句 だけ みりゃいいもんに見える 527 名前：login:Penguin mailto:sage [04/06/13 17:43 ID:Aj0tvs1r] >>524 冷静に考えてみ。 /つーか/var/logを含んでいるパーティションをfsckしている最中に その上にモリモリログを書いてたらえらいことになるぞ。 あと普通のSysVinitの構成は/をmountできないうちにsyslogdを走らせたりは しないから、syslogdがメッセージをバッファしたりもしない。 kernelがメッセージをバッファしていて(dmesgとかでみえるやつ)klogdが後から ファイルに書いてくれたりはするが、fsckはアプリとしてメッセージ吐くからダメなのだ。 528 名前：login:Penguin mailto:sage [04/06/13 18:41 ID:bthVhoxo] >>527 言われてみればそのとおりですが、ちょっと疑問があります。 ttp://www.a-yu.com/pub/lilo1_6.html のとおりシングルユーザモードでログインしてfsckしたわけですが、 確かログインした時点では/はマウントされてたと気がするのです。 それに fsck はルートパーティションの /sbin 以下にあるし。 プログラムをメモリにコピーしてから一時的にアンマウントしてるのかな・・・。 ファイルシステムへの理解が浅いのでこの部分で間違ったのかな？ 素直にfsckしなければ復旧できたとか。 529 名前：login:Penguin mailto:sage [04/06/13 18:47 ID:zxGnPCwq] >>526 NTFS信者ですが、どのあたりを見れば、わるいもんに見えますか？ 530 名前：login:Penguin mailto:sage [04/06/13 19:01 ID:O0msYNSV] Windows NTFS 共有領域 FAT32 Linux Reirserfs or XFS どうせこういう感じで使うんだからNTFSとLinuxのファイルシステムは比較対象にならないよ。 WinとMac比べてるようなもん。不毛。 531 名前：login:Penguin mailto:sage [04/06/13 19:54 ID:OI74V2PG] >>527 /のように無いと何もできないパーティションをfsckする羽目になると、 たいがいread-onlyでmountしてfsckする。よって/var/logには何も書けない。 532 名前：login:Penguin mailto:sage [04/06/13 20:06 ID:bEziBMJs] ファイルシステムトラブルに限った話じゃないけど、 システムがまともにブートしなかった時のコンソール メッセージってものすごく大事だと思う。 これをうまくログる方法ってないのか? いまどきシリアルコンソールで繋いで 端末からラインプリンタに出すわけにもいかないし... それはともかく、>>517のトラブルはswsuspとext3の合わせ技なんじゃないかなぁ。 最近のswsuspってfilesystem buffer cacheもハイバネの時に吐いたりするし、 2.4のext3もいまだに高速化のチューニングやってるよね。 解決方法の提案は今ありません。 533 名前：login:Penguin mailto:sage [04/06/13 20:29 ID:bthVhoxo] >>531 なるほど、納得です。 >>532 推量で書かれてますが、納得してしまいました。ありがとうございます。 swsuspをやるhibernateスクリプトって、モジュールアンロードしたり 一部daemonを止めたり周辺機器の接続を落としたりしてから swsuspしますが、スクリプトが走り始めてからでもキー入力は受け付けてるし、 他のプロセスも走ってるようだしで、こんなんでいーのかなーと思ってました。 今まで正しく動いていたので良いのかと思ってましたが。 でも、ジャーナリングの御加護はどこへ行ったんでしょうねぇ。 534 名前：468 [04/06/14 08:03 ID:z1H12v42] >>532 俺も同じエラー出てext3壊れたけど、 ハイバネなんか使ってないしIDEじゃなくてSCSI(RAID)だし、 ということで ext3 逝って良しということなのかな。なんだかなー。 535 名前：login:Penguin mailto:sage [04/06/14 10:42 ID:1qdNIOT1] >>532 シリアルコンソールつないでTeraTermで観察よろ 536 名前：login:Penguin mailto:sage [04/06/14 13:55 ID:jA/pYCxE] ext3ジャーナリングって設定しない限りはメタデータに対してのみだから、 fsckしないでも済む以上のことはないでそ。実データに対してのジャーナリング までやっていたら、遅くて話にならなくなるし。 537 名前：login:Penguin mailto:sage [04/06/14 19:13 ID:0HARJGC2] メタデータのジャーナリングしかやってないのなら、 ext3だろうがjfsだろうがxfsだろうが、 ファイルの壊れやすさはジャーナリングしないのと、たいして変わらないのでは？ 538 名前： mailto:sage [04/06/14 19:59 ID:rVKeY2mp] NTFS ってメタデータだけなのかな 539 名前：login:Penguin [04/06/14 22:45 ID:lmV9zskf] >>537 ファイルについてはそう。 ただファイル「システム」が壊れにくくなる。 540 名前：login:Penguin mailto:sage [04/06/14 23:01 ID:JqE6W7+Z] NTFSは貶められるほど粗悪じゃないし、崇拝されるほど完璧でもなく 個人利用には必要にして十分ないいFSだと思うが、ﾏﾝｾｰ派もｱﾝﾁも必死なんだよな・・・ 541 名前：login:Penguin mailto:sage [04/06/14 23:33 ID:jA/pYCxE] >>539 fs自体の壊れにくさもそうは変わらんよ。非ジャーナリングfsでは 障害時にfsckで全ディスクを舐める必要があるってだけで。 542 名前：login:Penguin mailto:sage [04/06/15 00:25 ID:7cOhxF1c] >>536 519のログを見ると、メタデータが壊れているようなので、まさに 「ジャーナリングの御加護はどこに」 という気分になるな。 543 名前：login:Penguin mailto:sage [04/06/15 10:56 ID:PTlfPUnj] ext3ってジャーナリングしてたんだっけ？ 544 名前：login:Penguin mailto:sage [04/06/15 17:08 ID:+v2UNpKs] えぇー！ 545 名前：login:Penguin mailto:sage [04/06/15 21:27 ID:qDwhCLTh] >>541 ext2 -> ext3 という話なら、そうかもしれんが、 一般論としてのジャーナリングであれば>>539が正しい。 546 名前：login:Penguin [04/06/16 17:18 ID:LjS/tfsK] ジャーナル部分のバグで、更に壊れる可能性アップ とかいってみるテスト 547 名前：login:Penguin mailto:sage [04/06/16 21:19 ID:E15QbflM] 昔、ext3でログのsyncが、vfsのバグで上手くいかなくて、 壊れるって言ってる人いたけれど、もう直ってるんだよね？ 548 名前：login:Penguin mailto:sage [04/06/16 23:15 ID:Jb/6MACX] sync2回打たないといけないとか、いろいろ噂流れてたなぁ 549 名前：login:Penguin mailto:sage [04/06/16 23:25 ID:HOY5xnPZ] sync for me sync for you sync for god 550 名前：login:Penguin mailto:sage [04/06/17 00:29 ID:YJjJ3vOr] >>547 IBMの奥山が広めたデマだな。 ・ext3が.journalというファイルにログを書いていたこと ・LinuxがHDDにraw deviceを用意してないこと に着目してjournalもバッファされるからトランザクション性がないだろ とか言ってた。彼のページにまだ記事が残ってるだろうが、 彼はFreeBSDのsoftupdateマンセーだったので journaling fs自体否定されてるぞ(w 551 名前：login:Penguin mailto:sage [04/06/17 00:33 ID:ngS+Tu6m] >>550 ところでsoftupdateって実用に耐えるようになったのだろうか？ 552 名前：login:Penguin mailto:sage [04/06/17 05:14 ID:vJ7TJ/hx] >>551 FreeBSDではかなり前からsoftupdateがデフォルトで有効になっているぞ。 つーか実際に運用されているサーバでsoftupdateを有効にしていないものは ほとんど残っていないと思われ。 553 名前：login:Penguin mailto:sage [04/06/17 12:37 ID:Cjys0RLv] >>550 奥山シンパじゃないが... >journaling fs自体否定されてるぞ(w おまえ、ちゃんと文章読めや。 奥山はjournaling自体をを否定してねえだろ。 ただ（あの当時の）journaling fsはメタジャーナリングしかなくて、 メタジャーナリングじゃデータ領域の安全性はsoftupdateとか、何か安全性を 保証することをしないといけない。 なのに、データ領域への書き込みはlinuxのvfsが無茶苦茶asyncしまくりのタコな 状態なのに、それに依存しまくっているから問題だって言ってるだけだろ。 たしかにext3に関して勘違いした文章は書いているが、結局メタジャーナリングじゃ データ領域の保証はされてないってところでは、現状のlinuxのvfsってどうなのよ。 linux使ってる身としては、結構気になるんだけどな。 #たしか、/.でも、奥山の間違いの指摘と、ジャーナリング機構の堅牢性の話は出たが、 #その部分で叩くばかりで、linuxのvfsの話はスルーされてたなぁ。 #おまけに、>>536の指摘が出るまで気づいてないような、勘違いレス #（ジャーナリングしたのになんでデータが飛ぶの？みたいな）も出てるし。 554 名前：login:Penguin mailto:sage [04/06/17 13:39 ID:r+RGGHNP] データ領域もジャーナリングするファイルシステムってないの？ 555 名前：login:Penguin mailto:sage [04/06/17 13:58 ID:8qg3KkNk] >>553 xfsが自前のvfs使ってるはず。 他のext3とかreiserfsとかjfsは 腐ったvfsを使用しているという点ではダメだと思う。 556 名前：login:Penguin mailto:sage [04/06/17 14:37 ID:Uff0XKD4] vfs直そうよ 557 名前：login:Penguin [04/06/17 15:14 ID:wT98rTfg] www.dd.iij4u.or.jp/~okuyamak/Documents/NetworkFileSystem.Tune.4.html www.tac.tsukuba.ac.jp/~yamato/samba/11000/msg00478.html 論争ネタはこれ前後ですかね？ --- ext3 層が ext2 に Journal を書いてくれと頼んでも、 Journal 記録が disk に書き込まれる保証はない --- これは vfs と ext2 fs がジャーナルの書き込みと順序の保証をしないという事かな？ これに対する典型的な反論は ・古い情報に基づいてる 　　→ということはもう vfs は直っている？ ・HDD のファームがある時点でのデータまで全て書き終えた事まで保証しないとだめなので softupdates も意味無いんでは 　　→ではバリア命令を送れば問題ない？ …以上だったと思う。訂正よろ。 あと、どこかに奥山氏だったか、linux の fs は順序フラグ付けても無視する、 と言うようなML投稿も有ったと思うがみつからねー。(syncじゃなくてorderの方) 558 名前：login:Penguin mailto:sage [04/06/17 22:20 ID:hxBNxHyy] >>554 RAID? 559 名前：login:Penguin mailto:sage [04/06/17 22:23 ID:7rYbXA9B] 俺もそう思ったがファイルシステムじゃない・・・ 560 名前：login:Penguin [04/06/18 07:40 ID:jzwiQCGa] >>542 まさにそうなんだよ。 ext2よりext3のほうがよく壊れる感じがしませんか？ 561 名前：login:Penguin mailto:sage [04/06/18 10:13 ID:xCDKeneh] しません。原因不明で壊れた事はないから。 ていうかファイルシステム破壊のような重大問題を 「感じがする」なんていいかげんな事で済ませたりしませんから。 562 名前：login:Penguin mailto:sage [04/06/18 10:31 ID:+hJM9jh6] 壊れた原因が判明するほうがまれだと思う 563 名前：login:Penguin mailto:sage [04/06/18 10:52 ID:BLXljFR0] >>554 Log structured は、比較的それっぽいと思うけど、どうなんだろう？ メタデータとデータを一筆書きで（場所を分けないで）ずるずると書いていく イメージなんだけど。 564 名前：login:Penguin mailto:sage [04/06/18 12:34 ID:Lnt6JO16] >>563 LFSはジャーナルだけのファイルシステムって感じだよね。 >>554 ext3が、data=journalオプションでフルジャーナルになるっぽい。 結局vfsは直ってるんですかね〜 直ってるってはっきり言ってるのを見たこと無いのでちょっと心配。 565 名前：login:Penguin mailto:sage [04/06/18 13:06 ID:S8bTS/o9] なんでファイルシステム関連は妄想ヲタが多いのかね。 566 名前：login:Penguin mailto:sage [04/06/18 13:14 ID:S7lg8ux/] >>565 おかしいところを具体的に指摘すると もっと効果的だよ。 567 名前：login:Penguin mailto:sage [04/06/18 15:25 ID:xbNkLRR6] >>566 っていうか、指摘できなきゃ>>565こそヲタの妄想でしかないよな。 568 名前：login:Penguin mailto:sage [04/06/18 16:00 ID:deyzjst3] >>564 vfsが治っていないと、今でも>>546ってことになるもんなぁ。 569 名前：login:Penguin mailto:sage [04/06/18 16:34 ID:xbNkLRR6] >>568 それはないはず。 たしか、奥山氏のページのext3に関する記述の（/.だったかな、の）反論として （奥山氏の推論）ext3はext2上にジャーナルデータを記述した一般ファイルを作る 　　　　　　　　→ジャーナルデータはvfs経由で書いてるだろう （反論）ext3では、ジャーナルデータの書き込みはちゃんと独自のルーチン使ってますね（プ というのがあったので、たぶんvfsが原因でジャーナル部分に影響することはないと思う。 570 名前：login:Penguin mailto:sage [04/06/18 17:45 ID:sVx+wkUC] 皆さんのカーネルに対する理解が、スケジューラやVM辺りで止っていて、 fsやnetにまで届いてないことは、よく分りました。 571 名前：login:Penguin mailto:sage [04/06/18 18:15 ID:xbNkLRR6] >>570 そう思いたいのですね:-) 572 名前：login:Penguin mailto:sage [04/06/18 18:26 ID:deyzjst3] >>569 ううむ。なるほど。 とりあえず ttp://www.atmarkit.co.jp/flinux/rensai/fs01/fs01a.html を見て 勉強します。 573 名前：login:Penguin mailto:sage [04/06/18 19:54 ID:SjQ17unD] >>564 >>230に対してコメントおねがいします。 574 名前：login:Penguin mailto:sage [04/06/18 21:08 ID:o0yQUQlF] >>560 ext2よりext3のほうが壊れ易いという声は良く聞くんだけど、 どのタイミングで壊れたかの話を聞かないと何とも言えないよな。 俺の場合は、ext3のjournal recoverで問題が起きたことはなかったんだけど、 以下の手順で壊した時にはかなり壊れた。 ext3 + swsuspで、ハイバネをかける ↓ まちがって他のカーネルで起動する ↓ readonlyで/がmountされるがext3なので結局journalがリプレイされる ↓ あわてて元のカーネルで起動する ↓ ハイバネしていたカーネルがjournalがリプレイされたことに気がつかないままリジューム ↓ shutdownする ↓ ジャーナルノード崩壊 orz journaling fsの原理だけ考えるとジャーナルノードがこけてもふつうのfilesystemになる だけのような気がするんだけど、ext3でジャーナルノードが壊れてる時は ジャーナルだけじゃなくモロモロえらいことになってる話が多いような。 JFSやReiserFSではそういう話聞かないから、ext3が壊れ易いってのはext3特有の問題 なんじゃないかな。 575 名前：login:Penguin mailto:sage [04/06/18 22:46 ID:rY2wiHpB] >>574 それは壊れたというよりオマエが不注意で壊してるだけじゃねーか馬鹿！ 576 名前：login:Penguin mailto:sage [04/06/18 23:42 ID:ErM3WTSg] なんでファイルシステム関係は妄想オタが多いのかね。 577 名前：login:Penguin mailto:sage [04/06/18 23:46 ID:AvZ78uxi] >>575 壊そうと思えば簡単に壊せるようじゃ困ると思わない? 578 名前：login:Penguin mailto:sage [04/06/18 23:47 ID:47LKkKdM] 壊そうとすればどれだろうと壊れるだろ 579 名前：login:Penguin mailto:sage [04/06/19 00:09 ID:BLhUJPcc] >壊そうと思えば簡単に壊せるようじゃ困ると思わない? >>577はファイルシステムの脆弱性のことを言いたいのか？ 580 名前：login:Penguin mailto:sage [04/06/19 00:14 ID:qBPMfpBi] >>558 RAID1でも、複数のディスクに同時に書き込んでいて、複数のディスクが 同時に事故(例えば停電)したら、同じエラーが出るんじゃない？ ファイルシステムのバグが原因ならもっと確実だろうけど。 >>574 linuxのハイバネって、確かswapパーティションに書くよね。 他のカーネルでswapのマウントまで行ったらリジュームできなくなると思うんだが。 だとすると、/のジャーナルリプレイ完了(開始？)後、swapのマウント前に 再起動(リセット？)したのかな？ずいぶん微妙なタイミングだな、と。 # 間違った仮定に基づいていたらごめんなさい。 581 名前：login:Penguin mailto:sage [04/06/19 00:38 ID:crb3z0Bs] swapパーティションにハイバネイメージを書いた後、 swapパーティションの先頭のシグニチャをいじってswapに見えなくする。 linux kernelはswapパーティションのパーティションIDではなく、 パーティションの先頭に書いてあるシグニチャでswaponできるか どうかを判定するようだ。 このへんmkswapしなくていい普通のUNIXとは違うんだよな。 だから、他のカーネルでブートするとハイバネイメージを書いた swapパーティションはswaponできないままブートプロセスが進行する。 (あと、ハイバネしないカーネルはroot deviceを先に、 ハイバネするカーネルはresumeのデータを読むためswap partitionを先に アクセスする違いがあるな) 最近のハイバネパッチは異バージョンのカーネルのハイバネイメージを 検出すると、破棄してクリーンブートを続行するかリブートするか選択できる。 つーかハイバネの話はスレ違いなので適切なところへ... 582 名前：login:Penguin [04/06/19 17:53 ID:Ojl/frYN] 盛り上がってまいりますた！ 583 名前：login:Penguin mailto:sage [04/06/19 19:24 ID:b7g1S+9G] >>557 Samba-JP MLの奥山のポストをよんでみたけど、 エレベーターシークを行なっているのはブロックデバイスのドライバだから (driver/block/elevator.c)XFSでも逃げられないのでは? ext3のjournalingに使われるjournaled block deviceドライバがfs以下にあるので これで回避できてるのかもよくわからないけど。 584 名前：login:Penguin [04/06/20 14:35 ID:u46dN04k] エレベーターアクション 585 名前：login:Penguin mailto:sage [04/06/20 16:25 ID:LnupTILL] (#ﾟДﾟ)ｺﾞﾙｧ!! 586 名前：login:Penguin mailto:sage [04/06/21 23:10 ID:0RsP8ti8] 上でRAIDとかfull journalとかとの比較がでてるけど、 どっちもdata領域をsync書き込みしたいという要望なのかな。 softupdateはasync書き込みに対してfilesystemを安定化させる手法だから、 kernelがbuffer cacheをflushする前に書き込んだ内容は電源切ったら消えますよ。 flushは30秒に1回がdefaultだから、最悪で30秒分もどってしまう。 奥山さんが言ってるdata領域の安全性というのは meta data領域とdata領域の整合性のことで、 data領域への任意の時点での書き込み内容を保証する話じゃないでしょう。 だからfull journalとは目的が少し違うわけで。 softupdateの場合は、metadata領域のupdateもdata領域のupdateも 同じkernel daemon processで処理されるけど、 journaling fsの場合、 (1) journal領域のupdate (2) metadata領域のupdate (3) data領域のupdate が全部別々のprocessになりうるから、 連携がとれてないとfilesystemが壊れうる瞬間がすごく長くなりますよね。 ext3の場合、(3)はext2とおなじbdflushを使っているのが気になります。 587 名前：login:Penguin mailto:sage [04/06/21 23:43 ID:eqKLWGgr] >>586 それは理解した上でext3のジャーナルデータの書き出し部がどうなっているのか とか、vfsがどうなっているのかっていう話になっているわけだけど。 588 名前：login:Penguin mailto:sage [04/06/22 07:03 ID:lX6e0lR+] ファイルシステムが壊れているわけではないけど、 定期的なfsckでたくさん不整合が見つかるもんなぁ。< ext3の場合。 589 名前：login:Penguin mailto:sage [04/06/22 08:16 ID:Kf20g4IL] 結局VFSが元凶ということでFA？ 590 名前：login:Penguin mailto:sage [04/06/22 08:20 ID:ZFd0MGIb] >>588 みつかんねぇよアホ。 591 名前：login:Penguin mailto:sage [04/06/22 08:21 ID:ZFd0MGIb] 己のスキルの無さとハードの不安定をファイルシステムのせいにしたがる奴が多すぎ。 馬鹿のひとつおぼえみたいにVFSとかぬかしてんじゃねぇよ。 592 名前：login:Penguin mailto:sage [04/06/22 08:55 ID:Kf20g4IL] 現象論しか語れない人はおいといて誰かVFSの解説してください それともLinuxユーザは所詮ソース読{ま|め}ない人？ 593 名前：login:Penguin mailto:sage [04/06/22 09:34 ID:bpmK8UtP] vfsの何を解説して欲しいの? このスレにも解説記事が上がってるでしょ? 594 名前：login:Penguin mailto:sage [04/06/22 11:08 ID:k9MXLi0G] VFSはｍｍと密接な関係にあるので、理解するのは容易ではありません。 595 名前：login:Penguin mailto:sage [04/06/22 13:28 ID:GDkTi28/] vfsにバグがあるか聞きたいんでしょうけど‥自分で読まないのかね 596 名前：login:Penguin mailto:sage [04/06/22 15:00 ID:k9MXLi0G] 「バグがある」と言いたいお年頃なんでしょう。

---

---

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

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