- 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/
- 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
- 333 名前：login:Penguin mailto:sage [2008/04/02(水) 23:57:54 ID:ljKkX6tm]
- reiserfs…
- 334 名前：login:Penguin mailto:sage [2008/04/03(木) 00:03:41 ID:itZB1pzN]
- >>333
LKMLみててビルドエラーしたよん系以外の話題でreiserfsはとんとご無沙汰。
あれはもうダメじゃないか？
- 335 名前：login:Penguin mailto:sage [2008/04/03(木) 00:16:25 ID:5AUHYNuG]
- 話題にならないということは、reiserfs3が安定しているということだ。
よいことではないですか。
- 336 名前：login:Penguin mailto:sage [2008/04/03(木) 00:19:23 ID:XQFAcyR9]
- 多分、JFSも超安定してるんだろうなあ・・・
- 337 名前：login:Penguin mailto:sage [2008/04/03(木) 01:06:02 ID:Ztawo/Fi]
- >>336
JFSはサンプルが少なすぎるのかもねｗ
まあ、俺はext3に裏切られてから、IBMを信じて使ってたけど。
- 338 名前：login:Penguin mailto:sage [2008/04/05(土) 14:39:51 ID:CsBMf95s]
- 正式ext4マダ〜？
- 339 名前：login:Penguin mailto:sage [2008/04/05(土) 17:01:10 ID:gcliPWD0]
- たぶん福田総理の辞任→新総理誕生とタイミングが同じになると思う。
- 340 名前：login:Penguin mailto:sage [2008/04/05(土) 22:37:23 ID:BOqKZkDS]
- >>338
正直新FSを名乗るほどは変わってないという印象
- 341 名前：login:Penguin mailto:sage [2008/04/06(日) 12:51:02 ID:2TQbeNBN]
- ext2→ext3よりは変わってるだろ
- 342 名前：login:Penguin mailto:sage [2008/04/06(日) 17:43:04 ID:Wl/OXr5s]
- 16TBを越えるストレージが必要になるまでは、reiserfs使ってたほうが良くない？
- 343 名前：login:Penguin mailto:sage [2008/04/06(日) 17:49:50 ID:u2gn5b5I]
- reiserは8TBまで
実際にハマってXFSにした。
- 344 名前：login:Penguin mailto:sage [2008/04/07(月) 21:57:37 ID:QCSgi87J]
- はよext4でないかなー。
Reiserやxfsはハードの進化に追いついてないし、JFSは死に体だし。
- 345 名前：login:Penguin mailto:sage [2008/04/07(月) 22:04:07 ID:W1D8Pi3p]
- >>xfsはハードの進化に追いついてないし
kwsk!
- 346 名前：login:Penguin mailto:sage [2008/04/07(月) 22:04:21 ID:jcVZQx+d]
- ext?がハードの進化に追いついてるかというとそれも疑問符が付くと思うのだが
reiser4の方が近代的でね？
- 347 名前：login:Penguin mailto:sage [2008/04/07(月) 22:09:03 ID:XafXBPQU]
- 死んだ子の年を数えるのは止めようぜ
- 348 名前：login:Penguin mailto:sage [2008/04/07(月) 22:14:16 ID:pnasWVod]
- ...zfs....
- 349 名前：login:Penguin [2008/04/08(火) 08:05:49 ID:vX51nrv+]
- >>332
＞ちなみに本日の測定結果
＞ext2: 470MB/s
＞ext3: 150MB/s
＞XFS: 70MB/s
ＪＦＳもやってくれー
- 350 名前：login:Penguin mailto:sage [2008/04/08(火) 12:40:57 ID:7jql+r0w]
- >>345
いまC2D対応やってます状態。xfs使うならPen4以前で。
- 351 名前：login:Penguin mailto:sage [2008/04/08(火) 12:42:54 ID:77bTVWBc]
- >>350
そのやってます状態のパッチは？
- 352 名前：login:Penguin mailto:sage [2008/04/08(火) 20:06:46 ID:t6pXtMUO]
- >>350
ああ、開発主体のSGIがスパコン屋さんなので、去年まではIA64メイン、
今年からはx86_64メインだからね。
x86_32 はどうしてもワンテンポ遅れるんだけど、正直それで困ってる人もいないという・・・
- 353 名前：login:Penguin mailto:sage [2008/04/08(火) 21:59:28 ID:kp2pJUVD]
- >>350
対応って具体的に何するの？
ちゃんとしたSMP対応した時点でマルチコア対応と変わらんし。
- 354 名前：login:Penguin mailto:sage [2008/04/09(水) 11:03:15 ID:XsC9hakW]
- >>353
普通そう考えるだろうが、そうじゃなかったのがXFSの凄い(?)ところ。
- 355 名前：login:Penguin mailto:sage [2008/04/09(水) 11:21:07 ID:irm1RyJp]
- ここまで具体的な数値またはコード、０。
- 356 名前：login:Penguin mailto:sage [2008/04/09(水) 13:21:43 ID:XsC9hakW]
- mm絡みのあのpatchとかlock絡みのあのpatchとか思い浮かぶのはあるんだが、
ゴミの山みたいなpatchの中から探し出してくるのがダルすぎ
定量的に比較したことは無いが、ext3はあれほどpatch多くない気がするがどうなんだ?
- 357 名前：login:Penguin mailto:sage [2008/04/09(水) 13:29:32 ID:P7VWxNnr]
- ext4でデフラグがようやく使えるようになると聞いたのですが。まだ未実装だっけか。
しないとパフォーマンス悪いってのはやっぱ、
linuxでは「必要ない」、ではなく「できない」の間違いだったってことですよね。
- 358 名前：login:Penguin mailto:sage [2008/04/09(水) 13:42:10 ID:KQOYg6Em]
- 今時のHDDにデフラグって必要ないんじゃないの？
- 359 名前：login:Penguin mailto:sage [2008/04/09(水) 13:48:54 ID:XsC9hakW]
- ext4の本流にはまだmergeされてない。
が、NECの人が頑張っている流れで実装はある。ext3用のも。
ext2/3ではデフラグが必要ないというより、開発当時の環境では、
デフラグのコストが性能の低下より大きかった、という話じゃないかな。
最近のドライブの大容量化や高速化でそうも言っていられなくなっただけ。
- 360 名前：login:Penguin mailto:sage [2008/04/09(水) 16:46:40 ID:bJQ+WBXU]
- どんなに断片化に強かろうが、使っていれば少しづつ断片化していく訳だが
サーバ市場で普及が進んだおかげでLinuxを長期運用する例が増え
比例して断片化の進み具合やその影響も馬鹿にならなくなってきて
それを解消したがる顧客の声もそこそこの規模になり
更にext4は状況によってext2/3より断片化が発生しやすくなってしまった。
このような時代の流れによりNEC開発陣はデフラグツール開発の大義名分をゲット。
金庫番との死闘と末、開発費を捻出させることに成功したのであった。やったね。
こうですか？わかりません＞＜
- 361 名前：login:Penguin mailto:sage [2008/04/09(水) 17:00:20 ID:KQOYg6Em]
- HDD側のキャシュ増やした方がいいような？
- 362 名前：login:Penguin mailto:sage [2008/04/09(水) 18:30:34 ID:LVCZieeg]
- >>360
発想が昭和の人って素敵って感じだね。
- 363 名前：login:Penguin mailto:sage [2008/04/09(水) 18:46:45 ID:5v+cawCi]
- 俺デフラグずっと眺めてるの好きなのでぜひグラフィカルなUIを用意してもらいたい。
- 364 名前：login:Penguin mailto:sage [2008/04/09(水) 23:04:39 ID:HmwSCQL2]
- >>363
win98のころのブロックが移動して色変わってくの好きだったのに2ｋぐらいから
ただの棒になって色変わるだけになってつまんなくなったな
- 365 名前：login:Penguin mailto:sage [2008/04/09(水) 23:44:17 ID:OcdXE9xM]
- ブロックのやつはそれこそDOSな時代からだよ。
あれは趣があった。
- 366 名前：login:Penguin mailto:sage [2008/04/09(水) 23:57:02 ID:MHOGD1vi]
- 乗せたらダマス 魔法の絨毯 騙され続けて四半世紀だな
デフラグってプラセボつーか依存だよね。3日開けずにやっている香具師いる。
- 367 名前：login:Penguin mailto:sage [2008/04/10(木) 00:23:32 ID:A4V/r+Uq]
- デフラグを高速化するために最新のHDDを買い、
HDDがフラグメントしないようにデータをあまり書かない。
そんな時代も俺にはありました・・・
- 368 名前：login:Penguin mailto:sage [2008/04/10(木) 00:40:21 ID:sVUazSs4]
- 神経質な奴ほどデフラグ中毒になりやすい。
デフラグ中の画面を延々見てる奴。
洗濯中にグルグル回ってるのを延々見てる奴。
両者は似ているようで少し層が違う。
- 369 名前：login:Penguin mailto:sage [2008/04/10(木) 00:53:04 ID:M4lYQAYA]
- defrag中毒のヤシはLFS系のfsつかえばいいのに
- 370 名前：login:Penguin mailto:sage [2008/04/10(木) 01:30:53 ID:NY5kJFee]
- デフラグの画面は人間の生産性を驚異的に落とす最悪のGUIなので
ライフハック（笑）的には真っ先に削除されるべき
- 371 名前：login:Penguin mailto:sage [2008/04/10(木) 01:49:42 ID:gvIBE6hj]
- LFSとか言われてもな
- 372 名前：login:Penguin [2008/04/10(木) 04:06:43 ID:Gfyr/fVJ]
- >>368
洗濯機のグルグルは気持ちが落ち着く
デフラグはイライラする・・真逆
- 373 名前：login:Penguin mailto:sage [2008/04/10(木) 10:21:47 ID:REpR0D1a]
- なんか洗濯機を眺めながら一人で酒を飲んでるって芸人がいなかったっけ?
- 374 名前：login:Penguin mailto:sage [2008/04/10(木) 10:49:40 ID:H34Gbw9O]
- 麒麟の非公園生活者の方（川島）だったな。
ちなみに今は洗濯機そっちのけで眞鍋かをりに乗っかってるとか。
- 375 名前：login:Penguin mailto:sage [2008/04/10(木) 15:59:42 ID:AsPLT2gw]
- >>350
C2D対応のソースまだぁ？
- 376 名前：login:Penguin mailto:sage [2008/04/10(木) 18:46:32 ID:4oJRCPdx]
- デフラグはHFS+のように、
自動デフラグ解消機能をFSに埋め込むって案はないの？
良くアクセスするファイルを、HDDの先頭に移動して高速化するって案は？
- 377 名前：login:Penguin mailto:sage [2008/04/10(木) 19:46:00 ID:g/S3sRn9]
- vxfsﾏﾝｾｰ
- 378 名前：login:Penguin mailto:sage [2008/04/11(金) 02:25:29 ID:xdk7g0sU]
- >>376
＞良くアクセスするファイルを、HDDの先頭に移動して高速化するって案は？
そういう製品もあるよ
ただHDDの先頭は汚染されやすい
（プラッタ上のゴミ等は遠心力で外周に向かいやすい）
ってことを考えると労力の割には微妙だなあと俺は思う
- 379 名前：login:Penguin mailto:sage [2008/04/11(金) 02:33:15 ID:2V7teuhD]
- 良くアクセスするファイルってほとんどの期間osのキャッシュ上にあるんじゃないかな?
ブート時の立ち上がりアクセスを連続化とかそういうのはlinuxじゃ難しそうだし、思想的に好かれなそう。
- 380 名前：login:Penguin mailto:sage [2008/04/11(金) 10:18:34 ID:gfqUbArl]
- >（プラッタ上のゴミ等は遠心力で外周に向かいやすい）
どんなファイルシステムだよ、と思ったら物理メディアの話か…
- 381 名前：login:Penguin mailto:sage [2008/04/11(金) 11:50:29 ID:NtcJovKM]
- HDDの中はクリーンでしょ・・・
- 382 名前：login:Penguin mailto:sage [2008/04/11(金) 12:54:43 ID:xdk7g0sU]
- >>381
プラッタとヘッダが接触する→破片が飛ぶ
あと誤解されがちだがHDDは密閉されていないので
埃等の進入も無いわけではない
- 383 名前：login:Penguin mailto:sage [2008/04/11(金) 14:27:02 ID:NtcJovKM]
- >>382
ヘッドが接触した時点でバッドセクタ発生で使用中止するでしょ。
気圧調整のために穴が空いているけど、フィルタシールされているから、
埃は外部から侵入しないよ。
- 384 名前：login:Penguin mailto:sage [2008/04/11(金) 15:04:27 ID:xdk7g0sU]
- フィルタがあるから進入しないというのは暴論だな
- 385 名前：login:Penguin [2008/04/11(金) 15:32:21 ID:EtOBVwEL]
- >>382
昔のHDDと違って今のはヘッドは接触してないでしょ。
といってもμとかそれ以下のオーダーで離れてるだけだけど。
- 386 名前：login:Penguin mailto:sage [2008/04/11(金) 17:24:52 ID:510mZMoh]
- しょっちゅうカコンカコンいってますが何か？
- 387 名前：login:Penguin mailto:sage [2008/04/11(金) 20:26:13 ID:2qIbW6EC]
- 破片云々や遠心力云々、
ヘッドの接触を前提に語ってる奴の言葉など、何一つ信用できない。
ちなみに、ヘッドの浮く高さはよく煙草の煙より狭いと言われるが
だからこそ、そのサイズのゴミさえ侵入しないように作られている。
- 388 名前：login:Penguin mailto:sage [2008/04/11(金) 20:31:20 ID:2V7teuhD]
- てかもうSSDになるんだから、ランダムリードのアクセスはかなり無視できるだろう。
書き込みの遅さと読み込みの速さをどううまくカバーできるかとかやってるのかな?
なんとなくだが追記型のが相性良さそう。
- 389 名前：login:Penguin mailto:sage [2008/04/11(金) 20:34:54 ID:9r4cpd5H]
- よくわからんが
コンタクト・スタート・ストップとかで接触するんじゃないの。
- 390 名前：login:Penguin mailto:sage [2008/04/12(土) 01:21:44 ID:zKuK+tHg]
- 非動作時等に接触するのは事実だが
そこが回転しているかどうか。
動いていない部分にヘッドが接触して破片がとぶって、
どれほどの衝撃でヘッドが着地するのかと。
- 391 名前：login:Penguin mailto:sage [2008/04/12(土) 02:04:05 ID:UJnKfLiT]
- >>388
現状ではランダムリードが遅いSSDなんて腐るほどある。
今のHDDでMemoryいっぱい積んだ方が安くて速い。
- 392 名前：login:Penguin mailto:sage [2008/04/12(土) 03:55:16 ID:ddANuM0+]
- >>390
>非動作時等に接触するのは事実だが
接触しない。今のHDDは電源が落ちると自動的にシッピングゾーンに
ヘッドがリトラクトされる。
現実問題として、実使用時においてゴミがとかヘッドが接触とかありえない。
一番可能性があるのが動作時に外部から強い衝撃を受けた時にヘッドがプラッタと接触し、
HDD内にマイクロな粒子が飛散する恐れがある。
この場合はバッドセクタが発生し、加速度的に増殖して壊れるだろう。
- 393 名前：login:Penguin mailto:sage [2008/04/12(土) 09:44:05 ID:B8KR3TA1]
- スレ開いて自作板かとオモタwwwww
- 394 名前：login:Penguin mailto:sage [2008/04/12(土) 10:19:10 ID:3VfCSwj0]
- ぐうぐる[しっぴんぐぞーん]→うぃきぺでぃあ
| ディスク停止時には磁気ヘッドとプラッタは接触しているが（この際の磁気ヘッド位置をシッピングゾー
| ンと呼ぶ）
- 395 名前：login:Penguin mailto:sage [2008/04/12(土) 11:29:27 ID:D6Z7h6V2]
- 全然話についてけないんですけどぉ〜＞＜
平常レベルに落としてよぉ〜＞＜
- 396 名前：login:Penguin mailto:sage [2008/04/12(土) 11:56:44 ID:ddANuM0+]
- >>394
ううん、すまん。俺が分解したIBMのHDDはdiscから完全にヘッドが外れて
ヘッド格納部に格納されるタイプだったんだよ。
このタイプの方がより安全だしね。
スレ違いなのでこのへんで。
- 397 名前：login:Penguin mailto:sage [2008/04/12(土) 13:21:02 ID:3VfCSwj0]
- >>396
それはload/unload(ramp load)方式のドライブで、IBM/HGSTのデスクトップ及び各社のモバイル
向けドライブに採用されています。停止時の安全性と省電力が売りですが、反面load/unload機構は
アームがrampと接触するため耐久性に疑問があること、及びload時にヘッドがプラッタに衝突する
こと、このため結局プラッタ外周部にデータを記録しないランディングゾーンを設けなければならない
ことなど、良いことづくめではありません。
一方停止時にヘッドが着陸するcontact start/stop方式はエンタープライズドライブ及びseagateの
デスクトップに採用されています。古典的な方式なので十分な安全性が確保されていること、
エンタープライズドライブはそもそも回りっ放しが前提なこと、外周の高速な部分が利用できること
などが利点です。反面、モーターが停止するとヘッドは必ず着陸するため、スライダの摩耗や
摩耗による微粒子の飛散などの問題は避け得ません。接触部分は削れにくいようにタフにできて
いますし、プラッタの記録面はゴミが飛んで来てもさらりと受け流すようにコーティングされています
(ふさふさの毛が生えている感じ)。その上に潤滑材が流れていますからまるでマットプレイです。
というようにどちらが一方的に優れているというわけではありませんし、どちらも製品寿命の範囲では
十分な耐久性があるのでもはや信仰の領域です。
……だったのですが、最近load/unload方式に革命的な進歩があり、最新の製品ではついに外周部の
ランディングゾーンがなくなりました。これはついに悲願のヘッドとプラッタの完全非接触が実現したと
いうことであり、load/unloadが一歩前に出たという印象です。
- 398 名前：login:Penguin mailto:sage [2008/04/12(土) 13:21:22 ID:3VfCSwj0]
- >>390
ランディングゾーンはデータ記録部分と違い、停止時にスライダが吸着しないようにわざとデコボコに
作られています。スピンドルモータが完全に停止するまでスライダが魔法的作用で浮いていられれば
よいのですが、現実には回転数が低下した時点で着陸するため、停止するまでガリゴリ削られまくり
です。この状態からモータを回し始めれば、浮揚するまでの間また削られまくりです。
>>387
景気よく動いていたドライブの電源を落とすと急激に冷えて内部の気圧が下がり、あろうことか
外界の汚れた空気を吸い込んでしまいます。もちろんフィルタで異物の侵入を阻むのですが、
世の中完璧には行かないもので。ハードディスクは温度変化が大敵です。
>>378
確かに内周で発生した微粒子は外周に向かって飛散しますが、スライダより遥かに軽い粒子が
吹き飛ばされることなくプラッタに着地するのは極めて稀なことです。また、そういうことが起こっても
困らないように設計されています。ハードディスク30年の歴史の積み重ねはそう短いものでもありません。
というわけでディスクの先頭に重要なデータを置いても困らないぜ? というお話でした。
っていうかバックアップ取っとけ!
- 399 名前：login:Penguin mailto:sage [2008/04/12(土) 15:40:45 ID:EsTwxU42]
- おまえら、たまにはスレタイ読んでくれw
- 400 名前：login:Penguin mailto:sage [2008/04/12(土) 15:58:09 ID:1E/jpGQt]
- コメントアウトされているようです。
- 401 名前：login:Penguin mailto:sage [2008/04/12(土) 15:59:16 ID:EsTwxU42]
- なるほどw
- 402 名前：login:Penguin mailto:sage [2008/04/12(土) 17:04:40 ID:OZPQRFfQ]
- この前、夜中、コンパイルしている時、地震があったんだ。
目が覚めるほどの。
その時、ハードディスクから、
「スチュ、チー、チー、チー」と、異音が…。
俺、「うぉーーー」
けど、なす術もなく、夜中で何もしたくなかったから、放ったらかしで。
翌日、どうしたもんかと思いつつ、
パッケージシステムのファイルダイジェストを確かめるコマンドで
チェックしてみたけど、大丈夫だったみたいだから、気にしないことにした。
思い出したから、書いてみた。
- 403 名前：login:Penguin mailto:sage [2008/04/20(日) 18:58:46 ID:plVuI/pr]
- reiserfsck --rebuild-tree って対象パーティション上に reiserfs らしきものを
見つけるとそれを復元してしまうもんなの？man reiserfsck を見たらそうも読み取れるんだが。
説明下手だけど今起こったことを書く。
/dev/hda9 上に dd で吸い出した別の HD の NTFS パーティションのイメージがある。
まあ、dd if=/dev/hdb1 of=~/ntfs.img をやっただけ。
ntfs.img の中には vmware の Virtual HD の中に reiserfs パーティションがある。
シングルユーザモードで立ち上げて reiserfsck --rebuild-tree /dev/hda9 を
実行したら /dev/hda9 のディレクトリツリーが ntfs.img の中の vmware.vmdk の
reiserfs パーティションの中身に変わってた。
当然ツリーだけが置き換わったんで、ファイルの中身とかはめちゃくちゃなんだけど。
もう何が起こったのかさっぱりわからん。こんなことってありえるもんなのか？
- 404 名前：login:Penguin mailto:sage [2008/04/20(日) 19:01:13 ID:plVuI/pr]
- ちなみに、ntfs.img の中の vmware.vmdk の中は reiserfs に
Debian をインストールしてました。
reiserfsck --rebuild-tree を実行したらこうなってた。
$ df -h
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/hda1 957M 400M 558M 42% /
tmpfs 502M 0 502M 0% /lib/init/rw
udev 10M 108K 9.9M 2% /dev
tmpfs 502M 0 502M 0% /dev/shm
/dev/hda8 1.9G 33M 1.9G 2% /tmp
/dev/hda6 12G 2.7G 8.6G 24% /usr
/dev/hda7 1.9G 1.6G 313M 84% /var
/dev/hda9 205G 79G 127G 39% /home
$ ls /home
bin dev initrd lib opt sbin tmp vmlinuz.old
boot etc initrd.img lost+found proc selinux usr
cdrom home initrd.img.old mnt root srv vmlinuz
- 405 名前：login:Penguin mailto:sage [2008/04/20(日) 19:37:17 ID:+sFhjnt6]
- Exactly（その通りでございます）
- 406 名前：login:Penguin mailto:sage [2008/04/20(日) 19:47:37 ID:plVuI/pr]
- 追試してみたら再現したんで自己解決。
結論は、
reiserfs のパーティションを dd 等で吸い出したイメージを
置いてあるパーティションでは reiserfsck --rebuild-tree を
絶対に実行してはいけない。
あらかじめ gzip で圧縮したり、rm で消しておけば大丈夫っぽい。
rm で消した程度だと見つけられるんじゃないかと思ったけど平気だった。
# mkfs.reiserfs /dev/hda9
# mount -t reiserfs /dev/hda9 /mnt
# ls /mnt
#
# dd if=/dev/hda1 of=/mnt/hda1.img
# ls /mnt
hda1.img
# umount /mnt
# mount -t reiserfs /dev/hda9 /mnt
# ls /mnt
bin dev initrd.img media root sys vmlinuz
boot etc initrd.img.old mnt sbin tmp vmlinuz.old
cdrom home lib opt selinux usr
debootstrap initrd lost+found proc srv var
# /mnt/bin/bash
bash: /mnt/bin/bash: cannot execute binary file
- 407 名前：login:Penguin mailto:sage [2008/04/20(日) 19:50:33 ID:plVuI/pr]
- >>405
やっぱそうなのか…。
長々と書いちゃったけど、既出だったらスマソ。
|
 |
