[過去ﾛｸﾞ]
/**ファイルシステム総合スレ その3**/ (983ﾚｽ)
/**ファイルシステム総合スレ その3**/ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
43: login:Penguin [sage] 04/12/03 11:56:21 ID:dgeNKlO1 >>34 > それともext3のhtree系の話のこと? 丁度それについて知りたかったのですがこれってまだ取り込まれてないのですか？ なんか随分前にこのパッチのことは読んだのですが現在の状況がよく分からない。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/43
44: login:Penguin [sage] 04/12/03 12:30:06 ID:q6jEdGAJ >>42 /usrや/bootだったらほとんど問題ないでそ。/をroにすると面倒だけど。 /homeや/varをrwにし、/tmpを/var/tmpへのsymlinkにしておいて一安心かと 思ったら、/etcがroになっているととんでもないことになったりするし。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/44
45: login:Penguin [sage] 04/12/03 21:14:05 ID:Y4rVC1lK >>43 htreeパッチ、orlov allocaterパッチとも2.6系には既にとりこまれているけど、 2.4系には入っていない。 2.4.21の頃まではTsoがhtreeパッチが作ってたけど、今は誰もやってない。 当時のパッチを単に2.4.28にあてるようにいじくったものだったら提供できると思うが、 2.6系でどのように修正+発展しているかわからないので、あまり意味ないだろう。 2.4.23の頃に使ってVM絡みっぽいエラーがボツボツでたので俺は今は使っていない。 たいして速くなった気もしないし(reiserfsのほうが速いのはかわらず) swsuspパッチとかみあってなかったのかもしれんが…。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/45
46: login:Penguin [sage] 04/12/03 23:54:22 ID:dgeNKlO1 >>45 ああ、やっぱり2.4系では採用されなかったのですか？ それは残念。 > たいして速くなった気もしないし(reiserfsのほうが速いのはかわらず) たしか1ディレクトリに大量のファイルがある（＞数万）場合のスピードの 向上が劇的であると理解しているのですが。 2.6でテストしてみようと思います。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/46
47: login:Penguin [sage] 04/12/04 01:55:17 ID:UhiuPqrX http://www.ussg.iu.edu/hypermail/linux/kernel/0112.0/1241.html とか見て、現実的な状況ではhtree + ext2(ext3)が有利と思ったんですけどねぇー。 まぁ、私が持ってる30MB/sec程度のノーパソHDDではわからないのかも。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/47
48: login:Penguin [sage] 04/12/12 06:25:10 ID:myzQvVjj もまいら、各ファイルシステムの特徴を一覧にまとめてくれ と荒れそうなことを書いてみるテスト http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/48
49: login:Penguin [sage] 04/12/12 06:27:03 ID:xB+9UMNp >>44 /etc て / に含めるべきでは？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/49
50: login:Penguin [sage] 04/12/12 10:57:32 ID:vRqjTsAW >>48 あらしていい？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/50
51: login:Penguin [sage] 04/12/12 11:01:28 ID:xB+9UMNp >>50 それが正しい行動なら。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/51
52: login:Penguin [sage] 04/12/12 11:48:38 ID:rpMi9cha >>48 ext2.......使いものにならない ext3.......使いものにならない reiserfs...使える xfs........使える jfs........使いものにならない nfs........使える http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/52
53: login:Penguin [sage] 04/12/12 13:40:10 ID:vRqjTsAW >>52 ext3 って使いものにならない？ うん、たしかに大量のファイルをおいてコンパイルしてるとき、 reiserfs の上でやった方が早いね。 それ以外の FS は使ったことないからなぁ。 xfs はバックエンドのファイルサーバで使っているけど、 どうせネットワーク後しだからあんまりわかんない。効果が。 なんで ext2/3 って reiserfs よりおそいんだろう。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/53
54: login:Penguin [sage] 04/12/12 18:20:28 ID:ocHfukbf そりゃ、reiserの方が後発で、ext2/3の弱点を分かってて作ったんだから、 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/54
55: login:Penguin [sage] 04/12/12 18:29:37 ID:xB+9UMNp reiserfs って地雷だった時期があるから、今でも恐いなぁ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/55
56: login:Penguin [sage] 04/12/12 18:46:41 ID:X0EcAtiE コンパイルなんてtmpfs上でやればいいじゃん http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/56
57: login:Penguin [sage] 04/12/12 20:52:34 ID:R8QWU/O5 >>52 nfsに突っ込むべきか？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/57
58: login:Penguin [sage] 04/12/12 23:25:55 ID:yhFIARcW LinuxのNFSの実装はあんまりいいとは思えんが… http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/58
59: login:Penguin [sage] 04/12/12 23:44:49 ID:AgGMobZ8 >>58 どのversionの話？ それによって大幅に変ると思うが http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/59
60: login:Penguin [sage] 04/12/13 00:01:00 ID:eO7ZY3lX >>59 NFSv4 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/60
61: login:Penguin [sage] 04/12/13 03:21:47 ID:H/cozg3/ v3モナー http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/61
62: 名人 [sage] 04/12/13 08:33:24 ID:avVmPVEh smbfs < cifs < ncpfs NFSはLinux同士なら悪くないと思う。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/62
63: login:Penguin [sage] 04/12/13 23:37:36 ID:95PMt4PJ ん？ そのわりには、linux-nfsのMLに日本人の投稿が 「全然」ないが？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/63
64: login:Penguin [sage] 04/12/13 23:55:34 ID:xBxaD+eb MLの投稿と何が関係あるんだろう? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/64
65: login:Penguin [sage] 04/12/14 00:18:43 ID:FHP8IZ/9 ext2fs 枯れてて、速い。ジャーナリング無しなので、マシンが突然落ちたときにはいやな目にあうかも。 ext3fs 現在のlinux用fsの主流。それだけで使う価値ありまくり。 reiserfs クソ jfs 内部ユニコード格納なので、デフォルトのロカールが変わっても、ファイルリネームの手間がない。アクセス速度は結構遅い。 xfs 大容量ファイルを使用する人向きらしいが、体感不能。 fat 軽い。多くの環境で使用できるので便利。cfブートだと結構linuxでも使われているかも。 ntfs linuxでは書き込みが不完全なのでどうでもいい。 tmpfs 最強。どんなfsもこれには勝てない。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/65
66: login:Penguin [sage] 04/12/14 00:49:55 ID:Z/EPu8nf vxfs 同バージョンであればSolaris←→Linuxでディスクのやりとりができる。 よって、マイグレーションにも使えるし、Linuxをバックアップサーバにしたりもできる。 いろんなメーカーのストレージでの実績もあり。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/66
67: login:Penguin [sage] 04/12/14 00:55:44 ID:i0IViqnH tmpfsのいいトコも書いてくれ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/67
68: login:Penguin [sage] 04/12/14 01:53:32 ID:Nupie2YP >>65 ext3fsの使う価値ありまくりって… reiserfsは互換性問題で懲りてる人は確かにいるな。結構速いけど。 >>67 速い。これに尽きる。 洩れはbuild時に多用している。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/68
69: login:Penguin [sage] 04/12/14 07:28:45 ID:pSiIop4Z tmpfs上でカーネルコンパイルが余裕で出来るぐらいにメモリー積んでみてー http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/69
70: 名人 [sage] 04/12/14 07:49:33 ID:2CTSu3na reiserfsは糞じゃないけどなぁ。小さいし速い。 jfsの方が糞。 xfsは大容量ファイル使わなくても速いよ。でかいけど。 fatはvfatだろう。 ntfsはデュアルブートでも無い限り要らない。 tmpfsは速い。 ext2/3もsecurity label, POSIX ACLとか追加されてるけど、 そろそろ他の選んでもいいと思う。 xfs + ext2/3 それなりのサーバ reiserfs + ext2/ext3 小さいサーバ/WS http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/70
71: login:Penguin [sage] 04/12/14 10:33:39 ID:LLGfYnI6 65じゃないがreiserfsは経験上、電源ぶち切りで3度ほどトんだ。 最悪だったのは、すべて壊れて/がすっからかんになってた。 マジで( ﾟДﾟ)ﾎﾟｶｰﾝ 漏れの中では糞認定。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/71
72: login:Penguin [sage] 04/12/14 11:25:31 ID:Wgu41CfB >>69 1.5から2GBくらい普通に積めるだろ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/72
73: login:Penguin [sage] 04/12/14 13:08:45 ID:pfRH5+g/ :/usr/src/linux-2.6.9 $make O=/tmp/2.6.9 ってやればいいじゃん。100MBもいらない。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/73
74: login:Penguin [sage] 04/12/14 13:56:42 ID:v+PWfJlk /{bin,lib} /usr/{bin,lib} くらいまでメモリ上に置いておきたい今日この頃。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/74
75: login:Penguin [sage] 04/12/14 16:39:59 ID:hJN0/6OR ext3の悪いところは、ベースのext2がタコなせいでジャーナリングの意味が薄いって ことだろうなぁ。ext2がufs並に強固だったらよかったんだけど…。 Solarisでもデフォではufs + journalingで、それで文句はあまりないわけだし。 Solarisの場合、業務用途ではお金かけてVxFS使うことも多いわけだけど、これは SANの共有diskで使うとかの特殊用途用なわけで。 >>66 そういえば、Enterprise WatchにVeritasのインタビューがありますな。 ttp://enterprise.watch.impress.co.jp/cda/storage/2004/12/13/4099.html http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/75
76: login:Penguin [sage] 04/12/14 17:59:33 ID:/g+UTXYg >>75 タコな部分の詳細ｷﾎﾞｿ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/76
77: login:Penguin [sage] 04/12/14 18:07:57 ID:Wgu41CfB >>75 ext3はext2から派生してるけど、コードがかなり書き直されてて ext2にジャーナリング加えただけよりは良いと思うが。 Linuxのvfsはどう思う？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/77
78: login:Penguin [sage] 04/12/14 23:27:20 ID:hJN0/6OR >>77 コードレベルではext3のコードは全面的に書き直されていていいのですが、 根本がext2というのは変わらんので…。 vfsについては、詳解Linuxカーネル第2版や2.6系のlinux/fs/buffer.c等のvfsな コードを見ると、以前のバージョンに比べて格段に良くなっている感じはするけど。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/78
79: login:Penguin [sage] 04/12/15 00:31:50 ID:pwu6u1JE >>78 話が具体的でない。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/79
80: login:Penguin [sage] 04/12/15 00:37:39 ID:ov/3B0xf おいおい、本当に書き直されてんのか? 詳解Linuxカーネルなんぞでvfsを語ってるあたりニオイますが。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/80
81: login:Penguin [sage] 04/12/15 00:54:47 ID:ddJLGS2q ソースくらい読めよ その程度でvfsを語ろうとしてるのか？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/81
82: login:Penguin [sage] 04/12/15 01:10:51 ID:AYmPYg/d >>80 自分で読んでいそうな78に比べて、お前はただの口だけしったかだな。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/82
83: login:Penguin [sage] 04/12/15 01:11:12 ID:AYmPYg/d >>79 バカ? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/83
84: login:Penguin [sage] 04/12/15 01:17:40 ID:ouw/CST4 このスレにソース読んでfilesystemの話をする香具師が後臨したためしはありませんが何か? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/84
85: login:Penguin [sage] 04/12/15 01:26:00 ID:v2MnbdG1 ドキュメントを読みかじった香具師ばかり。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/85
86: login:Penguin [sage] 04/12/15 06:09:21 ID:YAbTUvKH VFSとext2のどのあたりが不味いのか、ソースコードを含めて語れる人キボンヌ。 どっかで聞いたような風評は、この際どうでもいい。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/86
87: 名人 [sage] 04/12/15 06:20:00 ID:WrV5e22H >>71 漏れは、2.4, 2.5, 2.6混在時には何回か吹っ飛ばした。 あと、ジャーナル領域が壊れるとマウント出来なくなったりして悲惨。 復旧もext2/3の方が慣れてて楽だね。 最初はジャーナリング勘違いして、ファイルが復旧されないから糞だと思ってた。 reiserfsの場合、ファイルシステムの整合性しか見てないのにね。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/87
88: login:Penguin [sage] 04/12/15 09:41:13 ID:xrfZLoTA 2.4, 2.5, 2.6混在ってのはカーネルのバージョン? reiserfsのバージョンは3.6で統一されててもそうなるの? ブルブル… ところで、badblocksを避けてmkfsできるものは ext2/ext3 - できる reiserfs - できる jfs - できない xfs - できない という理解でいいのかな。(一応ググりましたが) ファイルシステム復旧の際に新しくbadblocksが見つかった場合に どう処理するかものかはよくわかってないが。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/88
89: login:Penguin [sage] 04/12/15 20:43:50 ID:eM8wwkt2 >>88 Bad Blockにddで書き込んでみたら？ 代替セクタに切り替わるかもしれん。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/89
90: login:Penguin [sage] 04/12/15 21:44:05 ID:m7kyNNhx badblockをファームウェアが修復してくれるHDDって いくらぐらいするもんなの? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/90
91: login:Penguin [sage] 04/12/15 22:29:01 ID:ddJLGS2q >>88 かなり前のHDDを使っていなければ bad block relocation はもう不要な機能といっていい http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/91
92: login:Penguin [sage] 04/12/15 22:43:42 ID:eM8wwkt2 >>90 5000円以上はするんじゃないかな。中古だともっと安いかも。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/92
93: login:Penguin [sage] 04/12/16 01:41:06 ID:pEinJtvl ちょっと不親切な説明だな 5年以上前から一般に出荷されるHDD（IDEやSCSI共)はドライブ自体にbad blockを 予備のblock（extra block)に自動的にremapする機構が入ってる つまり外から見ればbad blockが無い状態に保たれている （内部的なbad blockの数はS.M.A.R.T.でmonitorできる） OSからbad blockが見えるということはドライブのextra blockを使い果した状態で 確率的にbad blockが限度を超えたというより、ドライブ自体に何らかな問題があって 積極的にbad blockを作っている状態、つまりHDDが「死にかけ」の状態である可能性が 非常に高い HDDがハード的に死にかけの状態で使用を続けると、OSやfilesystemに関係無くドライブ データは加速度的に破壊されてしまう だから今のHDDでbad blockが見付かったら余計な操作をせずにRAIDであればHDDを交換 そうでなければ即刻umountして、dump等で残せるdataをbackupしてHDDを交換したほうがいい 昔はそういった機構が無いのでfilesystem自体がbad blockを弾かないといけなかったが 今はむしろそういう操作はしないほうがいいというのはその為 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/93
94: login:Penguin [sage] 04/12/16 04:23:35 ID:LjfbfI+A >>93 >OSからbad blockが見えるということはドライブのextra blockを使い果した状態で そうとも限らない。エラーセクタにはふた通りあって、ひとつは書き込みエラーに なるもの。これは物理的に壊れているもので、ドライブが自動的に代替処理を行う。 もうひとつは読み出しエラーになるもので、書き込み中の電源断などで中途半端に 書き込まれた状態になったもの。これはドライブが自動的に判断するわけにいか ない(何せデータが読めない)ので、本格的にエラーになる。coreを吐いたりpanic したりすることすらある。でも、読めないセクタにデータを書き込んでやるだけで 何事もなかったように直る。 というようなことはドライブメーカが配っているtechnical specificationとかその類の ものに書いてございます。楽しいので御一読あれ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/94
95: login:Penguin [sage] 04/12/16 11:48:10 ID:b0BZKqKb >>93, 94 勉強になります。 XFSのMLでも 「badblockを避けてmkfsするオプションはないか?」 という質問が 「badblockが出たHDDはどんどん壊れていくから そういう無理な使い方はせずに買い換えるべきだ」 という回答で一蹴されていました。 S.M.A.R.T.については http://smartmontools.sourceforge.net/ あたりを参考に勉強してみようと思います。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/95
96: login:Penguin [sage] 04/12/16 13:53:15 ID:ML1VldEV /.JPでLinuxのfsの話題が出たけど、このスレどころではないひどい状態… まあ、所詮はスラドだしなぁ。 ttp://slashdot.jp/comments.pl?sid=228729&cid=666241 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/96
97: login:Penguin [sage] 04/12/16 15:31:35 ID:tnC1mMEz 俺の経験だと「○○まわりが云々」って言う奴の知ったか率85%ぐらい http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/97
98: login:Penguin [sage] 04/12/16 18:02:37 ID:yUnPjm7f >>93 漏れは3年前ぐらいに買ったノート付属のHDDは使用半年ぐらいでbad blockが出た(--;。 買ってからほぼ毎日使い続けてるが、今でも問題なく使えてる。 実はﾗｯｷｰﾎﾞｰｲだったのか。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/98
99: login:Penguin [sage] 04/12/18 19:19:54 ID:AU3tzMNh >>74 遅レスだがそういうinitrdを作ってはどうか http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/99
100: login:Penguin [sage] 04/12/19 00:37:20 ID:8O1ekwSr 超初心者スレからやってきた者ですが、一つ気になることがあるので 質問させていただけないでしょうか。 私は最近Linuxを勉強し始めたのですが、NTFS(Windows2000)よりも ext3(RedHatLinux)のほうがファイルの読み書きが早くなったみたいで、 その理由がずっと気になっているのです。 どなたか詳しい方の御意見を聞かせてくれませんか。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/100
101: login:Penguin [sage] 04/12/19 00:44:13 ID:k3B6zMC/ >>100 残念ですが、詳しい人は、このスレには、いないです。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/101
102: login:Penguin [sage] 04/12/19 01:15:58 ID:rDY/v2x/ ファイルの読み書きにはそれぞれ何を使う話なんだろう? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/102
103: 100 [sage] 04/12/19 01:34:05 ID:8O1ekwSr 私は５ｋｂのテキストファイルを５０００個ほど作って削除するプログラムを 作ってみたのですが、どうもRedHatLinuxで実行すると、Windows2000よりも ４倍ほど速かったのです。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/103
104: login:Penguin [sage] 04/12/19 01:37:13 ID:rDY/v2x/ とりあえずLinuxは非同期書きこみのためディスクアクセスをさぼっているとか http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/104
105: 100 [sage] 04/12/19 01:51:41 ID:8O1ekwSr >>104 レスありがとうございます。私は「非同期書き込み」という言葉さえも 知らなかった超初心者なので、大変勉強になりました。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/105
106: login:Penguin [sage] 04/12/19 01:58:51 ID:C5xGXfQ+ ext3のmountオプション async と sync で比べて見てくれ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/106
107: login:Penguin [sage] 04/12/19 02:16:17 ID:MGT3nY1s Windows2000のNTFSはデフォルトでは UNIXで言うところのどういうmountになってるんですかね? USB/IEEE1394 HDDをひっこぬいた時の 「遅延書き込みを損失しました」 みたいなメッセージからするとasync相当なんでしょうか http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/107
108: login:Penguin [sage] 04/12/19 02:17:55 ID:k3B6zMC/ > USB/IEEE1394 HDDをひっこぬいた時の XP だと、遅延書き込みしないようにできるけど、2k はどうなの？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/108
109: login:Penguin [sage] 04/12/19 02:52:39 ID:4iE4RmFo > 「遅延書き込みを損失しました」 こんなメッセージ出すんだ。 linux なんかだと umount せずにこんなことしたら フリーズしそうだけどね。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/109
110: login:Penguin [sage] 04/12/19 02:58:43 ID:HUQiEobo よそでやってくれないかな http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/110
111: 名人 [sage] 04/12/19 07:40:54 ID:EVa/7se6 >>109 しないよ。 NTFSってファイルの削除は間違いなく遅い。 ジャーナリングのせいかもしれないが、xfsの方が圧倒的に速い。 ext3は使わないから知らない。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/111
112: login:Penguin [sage] 04/12/19 12:23:16 ID:mSdl8Z9C ファイルシステムの性能を測るベンチならあるけど、 信頼性を測るものってのはないの？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/112
113: login:Penguin [sage] 04/12/19 13:00:25 ID:IkhQEmHj >>112 >>7 から読みなおせ ━━━━━ 終 ━━━━━ 了 ━━━━━━ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/113
114: login:Penguin [sage] 04/12/19 13:02:33 ID:2HYnQJBL >>106 ext2のsyncはアホみたいに遅くないか？ 真面目にメンテされてないんじゃないかと思うのだが。 (どこかにext2 syncをそれなりの速さにすると言うWeb Pageがあったような気が) ext3は改善されているのかな？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/114
115: login:Penguin [sage] 04/12/19 13:03:36 ID:mSdl8Z9C >>113 何が「終了」なの？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/115
116: login:Penguin [sage] 04/12/19 13:15:24 ID:dC6I06gt >>114 教祖様が紹介してたやつな。 ISPかなんかの依頼仕事で2.2.16ぐらいまでやってたけど 勿論それ以降のカーネルにはそのパッチはあたらない。 syncは真面目にメンテされてないだろうね。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/116
117: login:Penguin [sage] 04/12/19 13:41:53 ID:BV27tiKs ext2のsyncは遅いのにsyncならない意味ないヤツじゃなかったっけ？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/117
118: login:Penguin [sage] 04/12/19 15:34:36 ID:ByTIpu85 また人の受け売りですか。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/118
119: login:Penguin [sage] 04/12/19 15:45:17 ID:BV27tiKs ext2なんて誰も使ってないんだし、受け売りでも腐っててもいいじゃん。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/119
120: login:Penguin [] 04/12/19 19:16:48 ID:8Y+ZrQby ( ﾟДﾟ) ﾎﾟｶｰﾝ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/120
121: login:Penguin [] 04/12/19 21:02:56 ID:nzVnVeqj ｘｆｓの方が速いとか使い門になるって言っている奴ほんとかよ。 どっかでｌｉｎｕｘのファイルシステムなかでおせーって記事読んだことあっぜ。 ベンチマークとかしてんの？イメージでは話してねえ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/121
122: login:Penguin [sage] 04/12/19 21:31:33 ID:VUG3agRr xfsがｲｲと言った名無しの2chﾈﾗｰがいたらしい。 xfsは遅いと書かれた謎の記事が存在したらしい。 嘘を嘘と見抜けないと2chを使うのは難しいらしい。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/122
123: login:Penguin [sage] 04/12/19 21:32:11 ID:J5yXbfhx わかったから教祖様の言うとおりFreeBSD使って 相談はUNIX板でやってくれ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/123
124: login:Penguin [sage] 04/12/19 21:38:55 ID:pCHaENfm ＼ ∩─ｰ､ ＼／ ● ､_ ｀ヽ / ＼( ● ● |つ | X_入__ノ ミ そんな餌では釣られないクマよ ､ (＿／ ノ /⌒l ﾆﾔﾆﾔ /＼＿＿＿ノﾞ＿/ / 〈 ＿_ノ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/124
125: 名人 [sage] 04/12/20 07:11:25 ID:hc+CVuZ3 >>121 fsによって得手不得手があるからなんとも。 xfsはファイルの削除が遅いとされてるけど、気にならないし。 少なくとも使い物にならないということはないと思うけど。 xfsよりreiserfsの方が速いと思うけどね。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/125
126: login:Penguin [sage] 04/12/20 13:07:40 ID:KZgGWO5h >>111 asyncという言葉を調べてくるように >>114 ext3もsyncは遅いし、ジャーナルもdata=journalなんてすると、とんでもない ことになる。デフォルトオプションでの運用しか考えられていない印象。 あと、data=writebackでext3使っているヤシも稀ににるようだけど、 ジャーナルの意味がほとんどなくなるんで、よく考えたほうがいい。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/126
127: login:Penguin [sage] 04/12/20 13:11:29 ID:lvPT1p3J 偉そうな人キター http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/127
128: login:Penguin [] 04/12/20 16:16:23 ID:5UdRzMj2 ext3 で盛り上がっているところ申し訳ないが、 udf は書き込み途中でブッチしたら危険？ やはり書き込みの途中でファイルシステムが「破壊」されている 瞬間があるのかな？ DVD-RAM 書き込み中にフリーズした場合なんかどうなるんだろうと思って。 映像用の DVD-RAM, +RW, -RW ビデオレコーダーなんか、家電だから、 パソコンよりももっと頻繁にブッチされることもあるんじゃないかなぁ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/128
129: login:Penguin [] 04/12/20 17:00:31 ID:5UdRzMj2 http://www.hitachi-system.co.jp/udf/sp/glo.html ここによると次のような説明がなされている。 「ファイルデータ、ファイル名情報、ファイル属性や位置情報を 分散管理することで、書き換え範囲を局所化し、 電源瞬断時や書き込み異常時のデータ破壊を最小限にします。」 具体的にはどれくらい耐性があるのだろう。 どのような条件で不整合が発生するんだろう。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/129
130: login:Penguin [] 04/12/21 23:54:02 ID:aXlAc1hr /や/bootも含めてすべてXFSにしちゃってgrubで起動出来ている人いますか？ grubのページ見るとせめてinitrdを読み込むためにも/bootだけはext2かext3 じゃなきゃいけないように思えたんですが。 でもふつー/bootは障害時の復旧しやすさを考えてextにしとくものですかね？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/130
131: login:Penguin [sage] 04/12/22 00:28:40 ID:JIylR8dv >>130 全部xfsにして使ってるよ。 grubなら jfs でも reiserfsでも大丈夫。パッチ充てればreiser4も可能 復旧も別手段で起動した時xfsが使える状態なら変わらない http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/131
132: login:Penguin [] 04/12/22 00:56:33 ID:EL67IdFL >131 おー！出来るんですか。 週末に環境の引越しをするので試してみます。 ちなみに復旧はKNOPPIXなどでXFSを読めるようなのでこれもやってみる つもりです。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/132
133: login:Penguin [sage] 04/12/22 00:58:49 ID:I7/1i9bf >>130 まあ、xfsならいいのかな？ reiserはオプションをつけておかないと大変なことになる可能性がある。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/133
134: login:Penguin [sage] 04/12/22 02:35:19 ID:77TfsAHw >>130 xfs+grubだと起動できない環境があったりなかったり。 まったく検証してはいないのでアテにならん情報だが、ちょっと前にインストールした 環境ではサックリ入ったんだが、先日インストールした端末は起動しなかったなあ。 Debianのインストーラでも警告が出るね。 調べる時間もなかったので、/ はext3で/tmpはext2、残りはxfsで逃げた。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/134
135: login:Penguin [sage] 04/12/22 02:58:05 ID:TYEnAFqh そりゃ、Debianのインストーラといっても、数あるわけで。正式版のwoodyの インストーラだとliloしか使わんから問題外だし、sidのβ版インストーラだと その日付によって挙動が違う。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/135
136: login:Penguin [sage] 04/12/22 04:21:16 ID:77TfsAHw いや、だからsidのインストーラだと標準でgrubを使うわけだが / をxfsにすると liloをインストールする流れになる。手動でgrubを入れようとすると、わざわざ 警告画面が出てくるってこと。 もちろんunstableだし、buildによって挙動が違うだろうが。 >>130は試してみるって話だが、問題が出る可能性もあるよって話なだけ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/136
137: login:Penguin [sage] 04/12/22 08:31:35 ID:0buNoT+s XFSのパーティションの先頭にgrubが入れちゃだめだからな お兄さんとのお約束だ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/137
138: login:Penguin [sage] 04/12/22 08:45:13 ID:JIylR8dv そういえばxfsのpartitionにgrubのstage1を入れると壊れるって話があったような 私は幸いMBRに入れることができる状態しか経験してないからそういったことには 遭遇してないがMBRに入れられない場合もあるしなあ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/138
139: login:Penguin [] 04/12/22 09:30:02 ID:zEZ8wPjW ブート用のパーティションにまで xfs を使わなくってもいいと思うんだがなぁ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/139
140: login:Penguin [sage] 04/12/22 10:18:40 ID:DgDR/B/w >>139 /boot に関してはそうだな。 カーネルを更新するとき以外マウントする必要の無い パーティションをXFS(やreiserfs)にするのは無駄。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/140
141: login:Penguin [] 04/12/22 10:56:42 ID:dmPGaRKi 面倒だから１パーティションでやりたい。 (swapはファイル) http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/141
142: login:Penguin [sage] 04/12/22 11:55:36 ID:Ee76SRLY kitty-guy みたいな広い空間がない限り、 1 パーテーションって何かあった時に余計に面倒。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/142
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 841 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.024s