[過去ﾛｸﾞ]
/**ファイルシステム総合スレ その3**/ (983ﾚｽ)
/**ファイルシステム総合スレ その3**/ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
412: login:Penguin [] 2005/05/07(土) 23:46:28 ID:RGubdeds >>405-411 ありがとうございます。>>71のような事例はそうそう無いということですね。 知り合いにReiserFSを使っている人が一人もいないので、参考になりました。助かります。 とりあえず試してみようと思います。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/412
413: login:Penguin [sage] 2005/05/07(土) 23:49:28 ID:V/FHntOf reiserfsってパーティションのdumpって取れないの？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/413
414: login:Penguin [sage] 2005/05/08(日) 00:40:37 ID:MfVnjZZl >>413 取れません。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/414
415: login:Penguin [sage] 2005/05/08(日) 09:24:42 ID:YfHNWr0g アンビリーバボー http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/415
416: login:Penguin [sage] 2005/05/08(日) 13:45:14 ID:Po17ElHx reiserfsのdumpツールがないのは痛いね。 しかたがないんでpartimageで代用してる。 partimageはマウント中のパーティションはバックアップできないんで KNOPPIXからpartimageでイメージ作ってる。 スナップショットを使えばオンラインでバックアップできるかもしれないけど やってみたことないんでわかんない。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/416
417: login:Penguin [sage] 2005/05/08(日) 19:13:10 ID:XF2QZrT2 reiserfsは、dumpの必要性がないファイルシステム(･`ω´･) http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/417
418: login:Penguin [sage] 2005/05/08(日) 19:36:58 ID:Ri0iZE9p Can I use "dump" and "restore" with ReiserFS? Any caveats? http://www.namesys.com/faq.html#dumprestoretar http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/418
419: login:Penguin [sage] 2005/05/08(日) 21:55:26 ID:Po17ElHx reiserfsのFAQが正しいとするとext2でもdumpは必要なさそうだけど 実際のとこどうなんだろ？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/419
420: login:Penguin [sage] 2005/05/10(火) 00:24:16 ID:sNZknnWi dump自体がレガシー。 HDDが数GBしかなかったころのバックアップ手法。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/420
421: login:Penguin [sage] 2005/05/10(火) 00:44:07 ID:J6n6iw5h >>420 数十〜数百GBのHDDのバックアップ手法キボンヌ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/421
422: login:Penguin [sage] 2005/05/10(火) 00:49:06 ID:Kc7Ph/cf >>421 nbd+mdでraid1とか。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/422
423: login:Penguin [sage] 2005/05/10(火) 01:10:39 ID:ACNMSWsB >>421 rsync+ssh http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/423
424: login:Penguin [sage] 2005/05/10(火) 08:01:40 ID:WSSMWoK/ >>422 RAID1は予防策であって、復旧には使えんだろ、バーカ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/424
425: login:Penguin [sage] 2005/05/10(火) 21:10:36 ID:sTZqqV00 旧態依然だといわれても他にdumpより良い方法がないからなぁ。なんかいいのある？/procとか問題なくrestoreできるなら正直なんでもいいんだけど。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/425
426: login:Penguin [sage] 2005/05/10(火) 22:35:10 ID:Rmgt7anG LVM http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/426
427: login:Penguin [sage] 2005/05/10(火) 22:42:22 ID:gz3WobZQ >>425 /procの中身を取らないという意味ならtar -l (--one-file-system)は？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/427
428: login:Penguin [sage] 2005/05/10(火) 23:03:04 ID:IQ56/S9J tarかよ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/428
429: login:Penguin [sage] 2005/05/10(火) 23:03:33 ID:IQ56/S9J IQ56 orz http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/429
430: login:Penguin [sage] 2005/05/10(火) 23:55:51 ID:6E7mrfUV cp -ax っつう手もあるな。dumpと比べてメリットがあるのかどうか知らんが。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/430
431: login:Penguin [sage] 2005/05/10(火) 23:58:02 ID:6fEbo/Kd てゆーか、dumpが無いって事は壊れないって事だ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/431
432: login:Penguin [sage] 2005/05/10(火) 23:59:08 ID:Kc7Ph/cf >>424 脳タリンが紛れ込んでるな。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/432
433: login:Penguin [sage] 2005/05/11(水) 00:02:10 ID:pQb5ltlh >>432 バーカ バーカ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/433
434: login:Penguin [sage] 2005/05/11(水) 00:17:03 ID:5zPh38xf dumpfsは？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/434
435: login:Penguin [sage] 2005/05/11(水) 00:46:32 ID:LKUcENHN 基本はスナップショットとれるfsをつかって、スナップショットをとったあと 時間をかけてお好きな方法でって感じで、特にこれといった決め手はないような。 >>433 バックアップにRAIDとかほざく馬鹿は放置しとけ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/435
436: login:Penguin [sage] 2005/05/11(水) 00:56:29 ID:h/eusWjs >>422はnbdって言ってるから、 ネットワーク越しにRAID1組んで 片方死んでももう片方から復旧させるという手法なのかな？ 瞬間的には逐次的なバックアップと見なせなくもないけど、 操作間違って消したらおしまいだしな。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/436
437: login:Penguin [sage] 2005/05/11(水) 01:01:05 ID:Y7lrbbGG sync終わったら切り離すって手法じゃね？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/437
438: login:Penguin [sage] 2005/05/11(水) 02:16:06 ID:DNCWvbPO >>431 ファイルシステムがいかに優れていて壊れなくても、人間というものはアフォで すぐ壊すからバックアップは必要なの。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/438
439: login:Penguin [sage] 2005/05/11(水) 09:45:35 ID:L5tbV2CV Red Hat Enterprise Linux 4のファイルシステム(ext3)上で ディレクトリをtarで固めると、順番めちゃくちゃに格納されちゃう。 Red Hat Enterprise Linux 3のファイルシステム(ext3)だと大丈夫。 何か変わった？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/439
440: login:Penguin [sage] 2005/05/11(水) 10:54:00 ID:s7L8K+Gr >>439 H-Treeのオンオフが違うとか? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/440
441: login:Penguin [sage] 2005/05/11(水) 19:42:45 ID:sC8+382H >>439 例えば、weekという名前のディレクトリ以下に、一定の並びでファイルが 入っていると仮定します。 $ ls -f week . .. Sunday Monday Tuesday Wednesday Thursday Friday Saturday H-Treeがオフの状態のext3上で $ tar cpf week.tar weeek を実行すると、その並びでtarファイルが作られます。 もし、H-Treeがオンの状態のext3上で同様に作りたければ、 week/Sunday week/Monday week/Tuesday week/Wednesday week/Thursday week/Friday week/Saturday のように、あらかじめファイル並びを記述した「week.order」を用意しておき、 $ mv week week~ $ mkdir week $ touch -r week~ week $ tar cpf week.tar week $ rmdir week $ mv week~ week $ tar rpf week.tar -Tweek.order の順番で実行すればOKです。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/441
442: 439 [sage] 2005/05/12(木) 11:40:23 ID:o3RQajAb >>440 >>441 いろいろ教えてくださりありがとうございます。 なるほど、H-Treeが原因のようですね。 H-Treeがオンの時、tarファイルに格納する対象としてディレクトリを 指定すると、その配下のファイルがまとめて固められてしまうので、 このような手順を踏んでいるのですね。参考にさせていただきます。 取引先に納品したtarファイルのリストが従来と違うと文句を言われて いたので、大変助かりました。 ただ、この方法だとディレクトリの深さが１段までなら大丈夫ですが、 さらにツリーが深くなると、再帰的な処理が必要になると思われます。 ちょっと考えてみます。何か良い案があればよろしくお願いします。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/442
443: login:Penguin [sage] 2005/05/12(木) 11:49:46 ID:dF2mIo3M FUSE: Filesystem in Userspace (2) http://japan.linux.com/kernel/05/05/11/2027206.shtml http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/443
444: login:Penguin [sage] 2005/05/12(木) 11:50:22 ID:9wWIeXgk tar で順番変わると何がマズいんだろ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/444
445: login:Penguin [sage] 2005/05/12(木) 12:28:16 ID:gklP+NyP ただ気持ち悪いだけだろ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/445
446: login:Penguin [sage] 2005/05/12(木) 13:35:05 ID:GQdBBjBd ファイル展開時に関連するファイルがディスク上に並んで置かれないため、 状況によってはシーク性能に影響するということが考えられるね。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/446
447: login:Penguin [sage] 2005/05/12(木) 13:56:42 ID:7uDI2iCm ひょっとして、cpioとか使ったことないのか? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/447
448: login:Penguin [sage] 2005/05/12(木) 14:24:06 ID:9wWIeXgk >>447 cpio だとどうなの? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/448
449: login:Penguin [sage] 2005/05/12(木) 15:08:55 ID:OCISmod/ find | sort | cpio -H tar http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/449
450: login:Penguin [sage] 2005/05/12(木) 19:23:24 ID:ZMvUpTPR >>446 tarにおけるアーカイブ順と、ディスク上の物理的な書き込み位置 が関係あるの? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/450
451: login:Penguin [sage] 2005/05/12(木) 19:37:23 ID:7uDI2iCm DQNをとりまく世界ではあらゆることが起きうるから tarにおけるアーカイブ順の如何で世界が滅亡しても不思議じゃない。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/451
452: login:Penguin [sage] 2005/05/12(木) 19:40:20 ID:zj5o6ZTq cpioだったら、たとえば、 find hogehoge | sort | cpio -H ustar -vo | gzip -9 > hogehoge.tar.gz みたいなことをやって、中間ファイルなしに ファイル名順にそろえられるとかじゃない? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/452
453: login:Penguin [sage] 2005/05/12(木) 20:24:17 ID:Jw/5ZFRB sortしちゃったら、Sunday→Monday→…の順じゃなくなるからダメでしょう？ 確かH-Treeがオンの状態でも、従来モードにフォールバックできるようになっ ていて、ファイルシステム上には格納順が残っているはずだから、その情報を 参照すれば良いんじゃないかな。readdir()の時はそっちを使え、みたいな。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/453
454: login:Penguin [sage] 2005/05/12(木) 20:37:18 ID:0fpm/QGJ >>453 VFSが挟まってるのにどうしろというんじゃい。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/454
455: login:Penguin [] 2005/05/12(木) 21:20:49 ID:mj9qIsKe >確かH-Treeがオンの状態でも、従来モードにフォールバックできるようになっ >ていて、ファイルシステム上には格納順が残っているはずだから、その情報を 詳しく http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/455
456: login:Penguin [sage] 2005/05/12(木) 21:34:05 ID:DO6cGhT1 >>451 どうせ滅亡するのはＤＱＮの脳内世界なのだから かってに滅亡させておけ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/456
457: login:Penguin [sage] 2005/05/12(木) 21:57:43 ID:4OU8dN/u >>453 sedなりperlなりでfilterすればいいだけでは？ 月の名前だったらsortだけでもできるけど。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/457
458: login:Penguin [sage] 2005/05/13(金) 00:07:38 ID:jHd5r8M+ H-Treeオンの状態だと、H-Treeオフの状態と比べて、意図したファイル並び という情報が欠落するわけだな。これは、POSIXでは規定されていないから 直ちに欠陥とは言えないが、この性質を利用したアプリケーションは困る。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/458
459: login:Penguin [sage] 2005/05/13(金) 00:27:12 ID:GNNJRhMr >>H-Treeオンの状態だと、H-Treeオフの状態と比べて、意図したファイル並びという情報が欠落するわけだな。 「意図したファイル並び」とはどう定義するんですか? 1秒未満の作成/変更時間を反映した順番とかですか? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/459
460: login:Penguin [sage] 2005/05/13(金) 00:38:31 ID:Jo1fj8OM >>458 > この性質を利用したアプリケーションは困る。 具体例プリーズ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/460
461: login:Penguin [sage] 2005/05/13(金) 07:52:11 ID:W8ukO34X fdcloneはいったんテンポラリにファイルを移動 -> 並び替えたい順番に 移動しなおす、という動作でファイルの並びを操作しようとするな。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/461
462: login:Penguin [sage] 2005/05/13(金) 08:08:40 ID:hKSAyzZk それは暇そうな操作でつね。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/462
463: login:Penguin [sage] 2005/05/13(金) 11:21:52 ID:nV+/skfG DOS使ってた方が幸せなんじゃないか? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/463
464: login:Penguin [sage] 2005/05/13(金) 11:48:36 ID:o2oNLWUR DOSのFDがそういう操作してたからfdcloneは わざわざそれにあわせてあげてるんじゃないの? もともとDOS使ってたほうが幸せな人向けのものな希ガス http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/464
465: login:Penguin [sage] 2005/05/14(土) 22:55:26 ID:Qor6xCD/ 何で話がそういう方向になるのかなぁ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/465
466: login:Penguin [sage] 2005/05/14(土) 23:33:01 ID:KKpbAvEx じゃあ戻しを試みると、 fdcloneとかのアプリは、fsによって挙動が変わる可能性があるってこと？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/466
467: login:Penguin [sage] 2005/05/15(日) 00:40:36 ID:Jypd01dn DOSからの人でファイルの内部並び順ウンヌン言う人いるけど、 本来保証されていないもの。 ファイル並び順の情報を保存したければ、別の方法で保存するのが筋。 検索の高速化のために内部で並び替えちゃう fs は多いよ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/467
468: login:Penguin [sage] 2005/05/15(日) 00:48:02 ID:4/Ea395X それじゃ、readdir()の実装はどう説明すれば良い？ dir_indexが有効だと"."や".."を含めて並びが乱れるよ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/468
469: login:Penguin [sage] 2005/05/15(日) 01:36:07 ID:eD5W67uQ >>468 乱れるからどうだっていうんですか? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/469
470: login:Penguin [sage] 2005/05/15(日) 08:51:23 ID:4/Ea395X >>469 ディレクトリリストを見るときls -flを使わない人ですか？ 先頭が"."と".."と想定しているプログラムが支障をきたします。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/470
471: login:Penguin [sage] 2005/05/15(日) 08:53:11 ID:wvbOfMkE そんなプログラム死ねよ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/471
472: login:Penguin [sage] 2005/05/15(日) 10:00:53 ID:FD02IJwt >dir_indexが有効だと"."や".."を含めて並びが乱れるよ。 >先頭が"."と".."と想定しているプログラムが支障をきたします。 結局dir_index(tune2fsでのH-Treeのスイッチね)は有効にするなということでFA? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/472
473: login:Penguin [sage] 2005/05/15(日) 10:29:56 ID:FuN4WlbD なんか馬鹿が腐れた自作プログラムの擁護するのに大変そうだね… でも、馬鹿がいくら擁護したところで、自分の馬鹿さ加減をより晒すだけだよ。 あと、暖かくなってきて恥垢臭がきつくなってきたんで、いい加減 包茎手術したら? 馬鹿は治せないけど包茎なら治せるんだし。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/473
474: login:Penguin [sage] 2005/05/15(日) 10:45:53 ID:+aIWv882 >>470 たとえばどのプログラム? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/474
475: login:Penguin [sage] 2005/05/15(日) 10:59:04 ID:bU0yJ5y/ >>470 そういう想定をするプログラムが悪いだけでは。 そもそも先頭が"." ".."になることを仕様として保証しているファイルシステムなんて そんなにないんじゃないか？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/475
476: login:Penguin [sage] 2005/05/15(日) 13:41:08 ID:G7HMkt+G >>475 ﾎﾟｶｰﾝ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/476
477: login:Penguin [sage] 2005/05/15(日) 14:24:42 ID:JIHdX8Y4 Error counter log: Errors Corrected by Total Correction Gigabytes Total EEC rereads/ errors algorithm processed uncorrected fast | delayed rewrites corrected invocations [10^9 bytes] errors read: 0 0 0 0 0 116.318 0 write: 0 0 0 121 121 162.833 0 verify: 0 0 0 1 1 109.298 0 Non-medium error count: 0 Error Events logging not supported smart-ctrl にてこんな感じのエラー吐いたんだけど、これってどう診断すればいいんだろう。 寿命と見るべき？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/477
478: login:Penguin [sage] 2005/05/15(日) 14:39:23 ID:tQyvF4oC >>474 自分がくらった例としてpmakeでこういうコードがあった。 (インデントは変えちゃってる) /* * Skip the first two entries -- these will *always* be . * and .. */ (void)readdir(d); (void)readdir(d); これコメントの意図通り動いてなくて悩んだYO。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/478
479: login:Penguin [sage] 2005/05/15(日) 15:45:04 ID:W4sCdrI7 ルートディレクトリならどうなるんだろ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/479
480: login:Penguin [sage] 2005/05/15(日) 15:52:00 ID:sBOcguWp >>479 お前素人?ルートディレクトリでも..はあるだろうが http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/480
481: login:Penguin [sage] 2005/05/17(火) 03:04:57 ID:PHaMhldM >>477 ハードディスクは日常的に細かいエラーを起こし、 そのエラー回数を集計したものを表示しているに 過ぎず、問題があって表示しているわけでは無いから 心配するのはまだ。 数値的には、エラーはほとんど無いし、 「uncorrected error」が発生していないし、 心配はいらないと思うよ。 ・121 回は無事に書き込みエラーが修正 ・116Gバイト読み込み ・163Gバイト書き込み ・109Gバイト検査 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/481
482: login:Penguin [sage] 2005/05/17(火) 06:19:31 ID:F2Fb99TS Ext3でナノ秒タイムスタンプ対応ってどうなってる？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/482
483: login:Penguin [sage] 2005/05/17(火) 08:13:44 ID:GLsf8WpD 見た事のない smartctl の出力だと思ったら、SCSI なのね。 びんぼーのぼくは、ATA でつよ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/483
484: login:Penguin [sage] 2005/05/17(火) 10:00:35 ID:gmUNXIDN >>480 スマソ、MS-DOSのFSと混同してた ちなみにDOSのルートには . .. 共無かった。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/484
485: login:Penguin [sage] 2005/05/17(火) 11:21:35 ID:kCITkC3l >>482 ext3のinodeにはdefaultではnanosecondなc/m/atimeを格納する余地がないので、 big inodeにしないといけなかったような気がする。 linux-2.6.11.10ではfs/ext3/inode.cでは void ext3_read_inode(struct inode * inode) { ... inode->i_atime.tv_nsec = inode->i_ctime.tv_nsec = inode->i_mtime.tv_nsec = 0; となっていてkernel側では知覚はできるけどfilesystemからは読み取らないようになってるね。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/485
486: 477 [sage] 2005/05/20(金) 01:17:52 ID:yJ30u50y >>481 わかりやすい説明ありがとん。smartctl の導入ページはあっても、 情報の分析ページが無くてこまっていました。本当に３Qでふ。 >>483 6年前の PC で未だに Socket 7 だったり。 CPU が遅いからディスクで稼ごうとして FULL SCSI で組んだら 偉く高くついてしまった…orz http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/486
487: login:Penguin [sage] 2005/05/20(金) 03:03:41 ID:jSorVggC そういえばreiserfs4って頓挫したの？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/487
488: login:Penguin [sage] 2005/05/20(金) 10:00:27 ID:Tg7xbKnx した http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/488
489: login:Penguin [sage] 2005/05/20(金) 12:27:10 ID:yCDzmLUz >>487 reiser4ならあるけど、頓挫したのか？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/489
490: login:Penguin [sage] 2005/05/20(金) 13:14:12 ID:QWQg0Sx/ 頓挫だって？ 全てのpartitionがreiser4なオレのマシンはどうしたらいいんだ！！ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/490
491: login:Penguin [sage] 2005/05/20(金) 17:48:15 ID:gRG2z9TW >>487 ソース見せれ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/491
492: login:Penguin [] 2005/05/24(火) 21:28:52 ID:CcC3rd0B Linux って smart に関するチェックツールは標準でついていますか? SUSEとかRedHatあたりを想定して質問しています． http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/492
493: login:Penguin [sage] 2005/05/24(火) 21:40:49 ID:U6QwgWRd smartctl 標準で付いてるかはしらね http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/493
494: login:Penguin [sage] 2005/05/25(水) 02:05:38 ID:TyXMytcf >>492 FC3の場合、smartctlはkernel-utilsに入ってる。 標準と言ってもいいと思う。 FC-develの場合、smartmontoolsに入っている。 こちらは標準かはパッケージからは不明。 インストーラのスクリプトを読んでくれ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/494
495: login:Penguin [sage] 2005/05/25(水) 16:34:15 ID:E6SguD3j >>492 SUSEだと、まんまsmartmontoolsというパッケージに入ってるな。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/495
496: login:Penguin [sage] 2005/05/29(日) 00:10:18 ID:jMu2od1v Novell SUSE LINX Enterprise Server 9 評価版 にlustreが入ってたので試してみました。 フルインストールでもlustreは選択されてないので、 検索→lustreで出てきたパッケージを入れてインスコ で、time ddで性能計ってみた ローカル性能、1spindle ext2とext2上に作成したスピンドルに対してのI/O read(time dd if=/fs of=/dev/null) size___ext2_____lustre __4KB__778M/s___200M/s 128KB__776M/s___580M/s __4MB__777M/s___730M/s 128MB__777M/s___735M/s write(time dd if=/dev/zero of=/fs) size___ext2_____lustre __4KB___42M/s____38M/s 128KB___42M/s____78M/s __4MB___42M/s___122M/s 128MB___41M/s___121M/s lustre。。ext2上に作成しているのにもかかわらず ext2の3倍。。。syncしてるのか？？ あきらかにHD性能超えてて怖いのだが。。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/496
497: login:Penguin [sage] 2005/05/29(日) 04:05:10 ID:c3E3M3x2 Linuxのファイルシステムってなんでまともにsyncしないものが多いんだろ? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/497
498: login:Penguin [sage] 2005/05/29(日) 04:17:11 ID:TPP2iooT http://blog.livedoor.jp/shi3z/archives/23323373.html また、パフォーマンス上も問題があって、実際にLinuxでサーバを組んで、 30万個のファイルを置いてみたら爆発的に遅くなった挙句、ハードディスク が焼け死ぬという事態をひきおこしてしまい、以来なるべくWindowsサーバを 使っています。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/498
499: login:Penguin [sage] 2005/05/29(日) 04:28:35 ID:zSFo58bZ ファイルシステムってハードディスクの物理的な破損を引き起こす事が可能なの？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/499
500: login:Penguin [sage] 2005/05/29(日) 11:06:08 ID:twTCB58j 寿命を縮めるぐらいならできそうだけど、 焼け死ぬかねぇ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/500
501: login:Penguin [sage] 2005/05/29(日) 11:17:51 ID:gtLSw276 >>498 この人は ＞Linux関連のサーバを作って飯を食うようになってかれこれ6年経ちますが、 ＞いまだに全貌が把握できていません とか言ってWindowsサーバを使っているということは、 windowsの全貌を把握しているということなのか。 それはものすごくとんでもなくすごいことのように思われるのだが。。。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/501
502: login:Penguin [sage] 2005/05/29(日) 12:11:39 ID:hkr9w7J3 6年も使ってるのに把握できないなんてよっぽど... http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/502
503: 477 [sage] 2005/05/29(日) 12:32:20 ID:EBOrcVsP >>501 こんなやつが、Linux 鯖で飯を食ってる当たりが エセエンジニアの 臭いがプンプン。だいたい fs と hd の物理的破損が関係あるわけない。 何の根拠もなく、こんなのことを平気で書くエンジニアがいるなんて 自分の無能をさらしているようなもんだろ。そういうやつがいるから 漏れに尻ぬぐいが回ってきて困るわけだが…。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/503
504: login:Penguin [sage] 2005/05/29(日) 12:43:24 ID:80gG1moJ 誤 ＞Linux関連のサーバを作って飯を食うようになってかれこれ6年経ちますが、 正 ＞Linux関連のサーバールームを作って飯を食うようになってかれこれ6年経ちますが、 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/504
505: login:Penguin [sage] 2005/05/29(日) 12:50:32 ID:KKU89vSn sambaが激遅なのは、認める。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/505
506: login:Penguin [sage] 2005/05/29(日) 12:57:43 ID:OUUVBMqM 自爆スイッチを押しちゃったんだよ、いろんな意味で。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/506
507: login:Penguin [sage] 2005/05/29(日) 13:20:34 ID:jMu2od1v >>498 ファイルシステムごとに特性があるので、 用途に合わせてファイルシステムを選ぶ べきだと思いますよ。 ファイル数が多い用途ならxfsかな。 私は1500万ファイル作成の実績がある。 6年も何をやってたのでしょうかね。。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/507
508: login:Penguin [sage] 2005/05/29(日) 14:01:37 ID:c9+5TNiD >>496 lustreってどういうモノ？ >>497 いつの話をしている？ - どうせマシンが落ちたらおしまいだから、と割り切っていた。 - Linusが遅いのが嫌いだから、速度稼ぐため。 というのが昔の認識だったが。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/508
509: login:Penguin [sage] 2005/05/29(日) 14:39:56 ID:c3E3M3x2 >>508 今の話。いまだにext3ですらまともにsyncしとらんのじゃないかという話すら あるわけで。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/509
510: login:Penguin [sage] 2005/05/29(日) 14:40:53 ID:jMu2od1v http://www.lustre.org/ lustreは並列ファイルシステム、pvfsなども並列ファイルシステム 1台以上のPCでファイルシステムを構築する。 PC512台で1台当たり100GのHDを2個づつ持ってたら 100G×2個×512台＝ 100TBの大容量ファイルシステムを組める まぁ1台構成でもいいけど。 Lustreは1.2.4が無料公開 1.4系は有料です。 SuSEに入ってるのは1.2.1でした。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/510
511: login:Penguin [sage] 2005/05/29(日) 15:07:34 ID:NoZthknx >509 まともにsyncしなければならない状況って どこまでを対象(保証)するかというわけで、 lkmlで教祖様も、H.Reiserに「まぁ、頑張れや」 ってコメントを食らってたなぁ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/511
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 472 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.016s