06/12/24 16:29:15 xYVNmyrQ
マジックバイトの話よりこちらの方が重要かな。
>>352を見るとデータはほとんど __be16 か __be32 で渡されている。
マックのパーティションを読む場合に限ればパーティションテーブルの読み込みは、
ビッグエンディアンの決めうちで行われているように見える。
358:300
06/12/24 20:12:13 xYVNmyrQ
その他
fs/partitions/msdos.h
#define MSDOS_LABEL_MAGIC 0xAA55
fs/partitions/sgi.h
#define SGI_LABEL_MAGIC 0x0be5a941
fs/partitions/sun.h
#define SUN_LABEL_MAGIC 0xDABE
359:300
06/12/25 21:38:37 u5v64fWw
今日も連投マジすまそ。
アップルパーティションマップの仕様を見つけた。
URLﾘﾝｸ(developer.apple.com)
内容はほぼ>>352と同じ。
対象ディス鳥のインスコは
URLﾘﾝｸ(www.ne.jp)
ここを参考に行った。
以下、検証資料を載せる。
360:300
06/12/25 21:40:28 u5v64fWw
f-disk -l /dev/hda
/dev/hda
# type name length base ( size ) system
/dev/hda1 Apple_partition_map Apple 63 @ 1 ( 31.5k) Partition map
/dev/hda2 Apple_Bootstrap untitled 1954 @ 64 (977.0k) NewWorld bootblock
/dev/hda3 Apple_UNIX_SVR2 untitled 3941407 @ 2018 ( 1.9G) Linux native
/dev/hda4 Apple_UNIX_SVR2 swap 250879 @ 3943425 (122.5M) Linux swap
Block size=512, Number of Blocks=4194304
DeviceType=0x0, DeviceId=0x0
361:300
06/12/25 21:44:48 u5v64fWw
dd if=/dev/hda of=part.map bs=512 skip=1 count=63
hexdump part.map > part.txt
0000000 504d 0000 0000 0004 0000 0001 0000 003f
0000010 4170 706c 6500 0000 0000 0000 0000 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0000
0000030 4170 706c 655f 7061 7274 6974 696f 6e5f
0000040 6d61 7000 0000 0000 0000 0000 0000 0000
0000050 0000 0000 0000 003f 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
*
0000200 504d 0000 0000 0004 0000 0040 0000 07a2
0000210 756e 7469 746c 6564 0000 0000 0000 0000
0000220 0000 0000 0000 0000 0000 0000 0000 0000
0000230 4170 706c 655f 426f 6f74 7374 7261 7000
0000240 0000 0000 0000 0000 0000 0000 0000 0000
0000250 0000 0000 0000 07a2 0000 0033 0000 0000
0000260 0000 0000 0000 0000 0000 0000 0000 0000
362:300
06/12/25 21:45:28 u5v64fWw
続き
*
0000400 504d 0000 0000 0004 0000 07e2 003c 241f
0000410 756e 7469 746c 6564 0000 0000 0000 0000
0000420 0000 0000 0000 0000 0000 0000 0000 0000
0000430 4170 706c 655f 554e 4958 5f53 5652 3200
0000440 0000 0000 0000 0000 0000 0000 0000 0000
0000450 0000 0000 003c 241f 0000 0033 0000 0000
0000460 0000 0000 0000 0000 0000 0000 0000 0000
*
0000600 504d 0000 0000 0004 003c 2c01 0003 d3ff
0000610 7377 6170 0000 0000 0000 0000 0000 0000
0000620 0000 0000 0000 0000 0000 0000 0000 0000
0000630 4170 706c 655f 554e 4958 5f53 5652 3200
0000640 0000 0000 0000 0000 0000 0000 0000 0000
0000650 0000 0000 0003 d3ff 0000 0033 0000 0000
0000660 0000 0000 0000 0000 0000 0000 0000 0000
*
0007e00
363:300
06/12/25 21:48:02 u5v64fWw
0000000-0000060の解析
--------Sig--Pad--MapBlkCnt-PartStart-PartBlkCnt
0000000 504d 0000 0000 0004 0000 0001 0000 003f
--------PartName
0000010 4170 706c 6500 0000 0000 0000 0000 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0000
--------ParType
0000030 4170 706c 655f 7061 7274 6974 696f 6e5f
0000040 6d61 7000 0000 0000 0000 0000 0000 0000
--------DataStart-DataCnt--PartStatus-BootStart
0000050 0000 0000 0000 003f 0000 0000 0000 0000
--------BootSize--BootAddr--BootAddr2-BootEntry
0000060 0000 0000 0000 0000 0000 0000 0000 0000
364:300
06/12/25 21:49:58 u5v64fWw
以上、PPCの場合もネイティブで間違いないと思う。
もう一度謝ります。
連投すまそ。
365:login:Penguin
06/12/25 21:53:17 A+i14brz
さてここで>>300に問題です。
macパーティションの上にext3ファイルシステムを作った場合
どうなるでしょうか？
366:300
06/12/25 22:02:09 u5v64fWw
誤り訂正
アップルパーティションマップの仕様のリンク
URLﾘﾝｸ(developer.apple.com)
f-disk -l /dev/hda → mac-fdisk -l /dev/hda
>>365
どうなるって、とり方次第でどうにでもとれて意味がよくわからん。
現状は/dev/hda3がext3でマウントされていて、読み書きできてる。
確認不足な点があるなら、追加するよ。
367:300
06/12/25 22:10:13 u5v64fWw
もう一度誤り訂正
リンク先は>>359が正しかったorz
マジ申し訳ない。
368:login:Penguin
06/12/25 22:16:50 xhvW4o8W
謝りすぎすよｗ
369:login:Penguin
06/12/28 20:16:52 11msnvQ0
URLﾘﾝｸ(www.atmarkit.co.jp)
370:login:Penguin
07/01/04 23:31:25 krLFR/+F
Linux: Chasing Down Data Corruption
URLﾘﾝｸ(kerneltrap.org)
Linux: Data Corruption Bug Fixed
URLﾘﾝｸ(kerneltrap.org)
371:login:Penguin
07/01/05 23:50:17 9EtcSPvI
gfs興味あるけど、資料少ないなー
372:login:Penguin
07/01/06 09:56:21 RHHwlQBc
GFS使ったことあるけど、Maildir形式のメールサーバ×４台に使ったら、
ファイルアクセスが遅すぎて使い物にならなかった。
大容量ファイル向きだわ。
GFS2でどこまで進化してるのに興味あるな。
373:login:Penguin
07/01/06 12:01:58 iH08ipQn
使ったことあるならちょっと聞かせてくれ
gfsって、LVMで分割したブロックを他のPCに持って行ってネットワーク経由でアクセスするって考え方でいいんだよな？
（もちろん、冗長化とかでA+AとかA+B+P+Qとかのモデルを取る場合もあるだろうが）
で、LVMってのは、MMUのディスク領域版だよな？
ブロックに分割した領域が、セクタアドレスの再配置を伴って、見かけ一続きのブロック領域としてファイルシステムに提供されるという
なんか根本的に間違ってるかな
374:login:Penguin
07/01/07 12:14:00 kV7nDToe
>>373
セットアップ人任せだったし、結構前だから、もうあまり覚えてないなー。
でもファイル読み書きはSANや共有SCSIで読み書きして、
ファイルロックを専用のネットワークでやるんじゃなかったっけ？
クラスタ組んでる内の１台がロック管理用のサーバになって、
他のホストがそのクライアントみたいな。
で、LinuxのLVMって、まだSistina GFS時代の頃にSistina社が
オープンソースで提供したものだったから、
LVMもGFSも管理方法が似てるとかだったような…。
昔はググってもほとんど情報なかったけど、今はググれば情報あるんじゃない？
375:login:Penguin
07/01/09 01:43:47 1r/HKlFu
鯖運用するのにFSを何にするのかついつい迷ってしまう。
面倒だから ext3 でいいよね?
376:login:Penguin
07/01/09 07:37:31 pFKWUuBq
ファイルがぶち壊れるの、fsのせいかと思ったら、原因はmmap()だったのか…
URLﾘﾝｸ(kerneltrap.org)
377:login:Penguin
07/01/09 08:09:00 8ySvgupC
こんどはgetdentsが遅いって話になってるな。
378:login:Penguin
07/01/13 00:17:35 hhd3ra9J
ジャーナリングファイルシステムが保証するのはメタデータだけらしいですが、
逆にいうとタイムスタンプとかファイルサイズのメタデータが更新されてれば
ファイルの中身は正しく更新されたと考えていいんでしょうか？
379:login:Penguin
07/01/13 00:18:27 /hTyXuuv
んなわけない
380:login:Penguin
07/01/13 08:50:01 LPgOApau
メタデータの何を保証してると思ってるんだ?
381:login:Penguin
07/01/13 13:50:32 7SZBdiSI
保証されるのはメタデータの一貫性じゃね？
データそのものはロストしてもファイルシステムの
健康は損なわれないってことでしょ。
382:login:Penguin
07/01/13 14:40:37 /ysw0X03
希望と中途半端な理解がごたまぜになった妄想
383:login:Penguin
07/01/14 11:07:16 NA5ZaSYQ
chattr コマンドでは dump コマンドによるバックアップ対象に
含めるか否かなどのフラグを操作することができますが、
これらのアトリビュートは ext2/3 特有のフラグです。
xfs や jfs でも同様のアトリビュートの仕組みはあるのでしょうか？
384:login:Penguin
07/01/17 10:59:30 XCRonxTk
>>217
古いネタになりますが..
ext3におけるジャーナル情報の記録はJournaling Block Device Layerを
通して行なわれるのであって、Generic Block I/O Layerが用いられるわ
けではないため、リクエストのソーティングなどは行なわれないのでは
ないでしょうか?
385:login:Penguin
07/01/17 11:29:42 83gvpb7N
>>382
つまりlost+foundにバックアップを取っておけば
いざというとき幸せになれるということですね？
いい意味で
386:login:Penguin
07/01/17 12:45:07 wR6IvIw/
>>384
今は奥山はジャーナリングの不整合っていうのは取り下げていたような気が。
387:login:Penguin
07/01/17 13:20:07 NH1vWgwK
>>386
ソース希望
388:login:Penguin
07/01/17 16:06:16 wR6IvIw/
「書き込み順序にエレベーターシークアルゴリズム などを用いるので、
Journal ファイルへの > Journal 記録の反映順序保証さえない」というのは
最近言わなくなって、その前の「sync システムコールを呼び出しても、
保証されない」というのを声高に主張するようになっているんだったかな。
syncしても書き込まれなのは事実だし。
389:login:Penguin
07/01/17 16:07:15 wR6IvIw/
あ、syncしても書き込まれないから、ジャーナリング不整合になるという結論は変化なしか。
390:login:Penguin
07/01/17 16:11:06 dKhI4BNe
で、その結論は正しいの？
391:login:Penguin
07/01/17 16:19:09 l/++G+GY
奥なんとかさんに聞いとけ
392:login:Penguin
07/01/17 16:36:28 XCRonxTk
最近のXFSはデータを準備してからメタデータを書くという噂を聞いたのだけど
ホント?
393:login:Penguin
07/01/17 18:07:01 BxDmthED
ext3のデフォと同じじゃん
394:login:Penguin
07/01/17 21:49:32 5iSAbmWu
BSDのsoftupdateもヤバくなるから取り下げたんじゃないのん？
395:login:Penguin
07/01/17 22:28:40 +AGvt5ET
>>394
ディスク側に持ってるキャッシュフラッシュのタイミングが気にいらん
ってな、話だっけ?
396:login:Penguin
07/01/18 01:21:11 QSNRktCd
>>395
あと、FreeBSD 5.x以降ではLinux同様syncしてもflushされないのがわかったのもある
397:login:Penguin
07/01/18 02:01:10 jUaHNsmy
>>395
> タイミングが気にいらん
そういう話じゃないだろう
ジャーナルに書き込んだがディスクはまだフラッシュしていない
この状態でクラッシュすると、OSはジャーナルを書き込んだと思っているが実際には書き込まれていない
398:397
07/01/18 02:03:10 jUaHNsmy
あ、すまん
>395はソフトアップデートの話だったな
スルーしてくれ
399:login:Penguin
07/01/18 02:13:17 4qrnvGep
キチガイって伝染するんだな
400:login:Penguin
07/01/18 10:40:41 vfB3lZBF
400
うん
401:login:Penguin
07/01/18 21:07:25 jUaHNsmy
ついでだが、>397の状態でも常に問題が起こらないとする
そうすると、ジャーナルは無用の長物だということにならないか？
402:login:Penguin
07/01/18 22:08:12 fQv5Q68V
問題では歩けど解決策が...ってことだろ
403:login:Penguin
07/01/19 02:41:03 6XfomkSC
ヒント：再起動
404:login:Penguin
07/01/19 12:31:32 T0ADJeSd
まさに伝家の宝刀
405:login:Penguin
07/01/19 20:39:33 4t6qqCPq
ジャーナル破損→再起動→ファイルシステム破損
>>403-404
本当にどうも有難うございました
406:login:Penguin
07/01/20 11:26:20 UaLVa0QY
壊れるのは書き込みの順序が原因で、syncしないことは別問題
407:login:Penguin
07/01/20 11:35:29 gfquQKqH
先生、質問！
１．書き込みの順序の問題が起こっているのはなぜですか？
２．syncしないことで起こる別問題って何ですか？
408:login:Penguin
07/01/20 12:10:54 KTOxmzQl
２は、データ自体が不正になってしまうことだな。
チェックポイント自体は正常に通過したけど、実際にデータが書き込まれていないってことだ。
チェックポイントを正常に通過しているから、ファイルシステム自体が壊れているわけではない。
これは、パフォーマンス上は有利であるが、非常に深刻な問題をもたらすことがある。
１は、媒体エラーによってもたらされるものだろう。
ジャーナルの再作成、fsckが必要になる。
lost+foundに前回のチェックポイント以降の更新データが保存される。
409:login:Penguin
07/01/20 12:17:24 gfquQKqH
返事がないようなので、もうひとつ
３．自由なタイミングでsyncできても、書き込みの順序の問題は解決できませんか？
410:login:Penguin
07/01/20 13:45:07 gfquQKqH
返事ぐらいしろよ
つまらないのでWindows2000の話
[書き込みキャッシュを有効にする] 機能を有効にすると、データが失われる
URLﾘﾝｸ(support.microsoft.com)
書き込みキャッシュが有効な場合の遅いディスク パフォーマンス
URLﾘﾝｸ(support.microsoft.com)
「この修正プログラムは、実装に伴うリスクのレベルを理解および承諾し、
適切なハードウェアの電源保護によってこのリスクを軽減できるという確信がない限り、
実装しないでください。」
411:login:Penguin
07/01/20 14:47:24 UaLVa0QY
書き込み順序の問題はディスクのcacheが原因
URLﾘﾝｸ(slashdot.jp)
412:login:Penguin
07/01/20 15:01:37 UaLVa0QY
>>２．syncしないことで起こる別問題って何ですか？
ディスクに確実に書き込まれたことを保証しないといけない場合に困る。
syncの呼び出し後にネットワークで書き込み終了を通知したが、
実際に書き込まれる前に電源が落ちるといったケースが考えられる
>>３．自由なタイミングでsyncできても、書き込みの順序の問題は解決できませんか？
syncによって順序を保証する手法もある。
詳細はlinux/Documentation/block/barrier.txtを参照。
但し、処理によっては実用にならない程遅い可能性もある。
413:409
07/01/20 15:15:27 gfquQKqH BE:454855493-2BP(0)
>>412
> >>３．自由なタイミングでsyncできても、書き込みの順序の問題は解決できませんか？
> syncによって順序を保証する手法もある。
実はここが聞きたかったわけで、そうすると
>>406
> 壊れるのは書き込みの順序が原因で、syncしないことは別問題
別問題とは言えないことを自ら返事されたわけです
414:login:Penguin
07/01/20 15:54:53 UaLVa0QY
>>413
確かにそうだけど…
softupdateなんかで依存の発生する場所全部にsyncを入れるのが
現実的？非現実的である証拠のデータが出せなくて申し訳ない
ですが…
415:login:Penguin
07/01/20 16:16:11 gfquQKqH BE:1078176588-2BP(0)
いえ、データ出すのは大変ですから
Windows2000でさえ両方の含みを残している
難しい判断なんでしょうね
416:login:Penguin
07/01/20 17:08:10 UaLVa0QY
ついでに、これも転載
URLﾘﾝｸ(lists.freebsd.org)
417:login:Penguin
07/01/20 17:25:35 snxMEiUl
>>416
そのスレを読んでいくと、ジャーナリングでもsoftupdate同様に
todays desktop drives can lie about writing data.
の影響を受けるっていう、このスレの流れと同様の話になっていっていますな。
418:login:Penguin
07/01/20 23:02:52 SqdA4hO3
ハードディスクが独自に高性能化を辿った結果、
書き込み順についてはどんなに直接sync命令しても確実に保証されるものではないってことかな?
今のhddじゃエレベーターシークアルゴリズムとかは意味がないか逆効果かもとどっかで見たことあるし。
419:login:Penguin
07/01/21 02:52:54 hY5qL1VD
>>418
SCSIとSerial ATA 2.5はFUAによってwrite cache有効時でも書きこみの完了を保証できる。
ので、ドライバがまともに実装されていればOK。
ATAはcache flushを保証する手段が用意されていないので何をやっても無理。
420:login:Penguin
07/01/21 20:35:19 4gtXWK3A
ZFSではwc対策はどうなっているの？
421:login:Penguin
07/01/21 23:48:40 AqF7ihH/
しかし、ジャーナリングファイルシステムって、電源断とかのトラブルでも
ファイルが壊れないようにするものじゃないのか。
実験室での使用なので、けっこう動作環境が良くないのは分かるけど
今日、ext3 また壊れてしまった。フォーマットからやりなおし。
土曜にバックアップとっていて良かった。
やっぱりXFSに移行するかな。
422:login:Penguin
07/01/21 23:55:06 xsvOt/km
ext3が何度も壊れ、
reiserfsの大パーティションのマウントの遅さが嫌になり、
XFSに行き着いて幸せになった俺
423:login:Penguin
07/01/22 00:14:17 ppnVbPRo
たしかに reiserfs はでかいパーティションのマウントに時間がかかるね
424:login:Penguin
07/01/22 00:19:23 RyHURUu7
ちょっと気になったのは、このスレの過去ログ読むとLinuxのVFSのせいで
XFSでもファイルシステムが壊れるって聞いたけど、どうなの?
425:login:Penguin
07/01/22 00:34:54 Mwx+Gzyg
XFSはファイルシステムが壊れるよ
ext3はファイルは守ってくれないが
ファイルシステムは守ってくれるので
まだ安心
426:login:Penguin
07/01/22 00:56:30 RyHURUu7
それじゃ、ダメじゃん。
427: ◆IIiDC8JS7w
07/01/22 00:59:28 v/DQ0Ap0
ZFS to the FUSE
まだα版だけど。。
つ URLﾘﾝｸ(developer.berlios.de)
428:login:Penguin
07/01/22 02:58:08 4mh5V91p
まぁいろいろ悩む前にUPS買えってことで。
あとは日々のバックアップ。
429:login:Penguin
07/01/22 04:59:17 g7VFvdpY
FUSEじゃ読み書きできますよっていう程度で、本格的に使うのには
全然向かないな…
430:login:Penguin
07/01/22 19:52:31 aXULs4Jv
GFS使ってる人、手ageて。
431:login:Penguin
07/01/22 19:54:33 I6ul0rfb
デスクトップでJFS使い始めました。
前はReiserFSでした。
今のところ無問題。
432:login:Penguin
07/01/22 21:44:43 CllrhvyS
>>421
どんなFSでも、ジャーナルにしてもRAIDにしてもファイルが壊れない
(壊れ難い)という認識は止めたほうが安全。
復旧を早くする方法論と割切ったほうがいい。
大切なデータはきちんとバックアップすること。
433:login:Penguin
07/01/22 21:46:12 vkPy7i3I
>>431
毎日cvsでgcc取ってきてビルドしてみて。
漏れは3年前emacsでそれやってたらfs壊した(XFS)。
434:login:Penguin
07/01/22 22:03:40 +MxoKgNb
XFS ってそんなに弱い子なのか。
435:login:Penguin
07/01/22 22:11:02 gyatXghJ
gentooでほぼ毎日何かしらをコンパイルしたり、
時々動画をエンコしたり、
毎日えろまんがを読み漁っていますが、
XFSは元気です。
436:login:Penguin
07/01/22 22:18:21 6fw9D8r3
ファイルシステムを何にしてもHDDガリガリさせるのは
寿命を縮めるだけだから、できることならあまりやりたくないね。
437:login:Penguin
07/01/23 00:06:35 yhm1O3f9
>>436
それじゃlocateが動くLinuxは使えんがな。
438:login:Penguin
07/01/23 10:58:00 SMWMFAIy
locate は使えば便利なんだけど
知らない人とか使わない人にとっては負荷が無駄過ぎるな。
デフォルトで動くディストリも結構あるんじゃないの。
439:login:Penguin
07/01/23 13:21:33 Dh6zD8CC
HDDの代わりにi-RAMとかフラッシュディスクを使えば解決
440:login:Penguin
07/01/23 13:28:42 dy5DSgJl
ガリガリ使えばHDDよりフラッシュのほうが寿命短いんじゃないの？
441:login:Penguin
07/01/23 14:18:58 Qe3f9h84
そこでMRAMとか相変化RAMとかですよ！
442:login:Penguin
07/01/23 14:32:40 L6fiHwdO
HDD の寿命とか気にしてたらまともに使えんだろう
443:login:Penguin
07/01/23 15:01:52 5Whe9XEV
フラッシュの方が圧倒的に短いわなｗ
444:login:Penguin
07/01/23 16:30:58 JInqPF8n
ハイブリッドハードディスク楽しみだよねえ。っと。
URLﾘﾝｸ(www.itmedia.co.jp)
# スレ違い。
445:俺用メモ
07/01/23 16:48:37 JpiPeEcZ
<kernel-src>/Documentation/filesystems/ext4.txt
NOTE: The "extents" mount flag is temporary. It will soon go away and
extents will be enabled by the "-o extents" flag to mke2fs or tune2fs
URLﾘﾝｸ(www.die.net)
For kernels after 2.3.3 there is no such limitation
URLﾘﾝｸ(www.die.net)
the maximum size is just under 1 TiB.
446:login:Penguin
07/01/23 17:00:50 xbr0LMQ0
FUA 関係なくデータのロストが防げるなら
フラッシュは大歓迎なんだけど、
そういう目的じゃないようなので
Intel の Robson でいい気もする。
447:login:Penguin
07/01/23 17:14:46 0oMO9Ojw
>>446
> FUA 関係なくデータのロストが防げるなら
ハイブリッドディスクはデータロストしないんじゃねぇ？
ライトキャッシュが不揮発性というのは大きいと思うんだが
448:login:Penguin
07/01/23 17:34:03 0oMO9Ojw
もちろん、ソフト側が正しく制御する前提だけど
449:login:Penguin
07/01/23 21:19:21 SMWMFAIy
フラッシュメモリってライトキャッシュに使えるほど
書き込み耐久性あるの？
450:login:Penguin
07/01/23 21:27:38 xbr0LMQ0
フラッシュに入る前にも当然8MB程度の
RAMがキャッシュメモリとして確保されていると思われ。
なのでその部分はやはり揮発すると思う。
451:login:Penguin
07/01/23 21:44:21 L4TUXWzd
>>450
揮発するといってもトランザクションを実行するくらいの
コンデンサ容量は確保されてるでしょ・・・・
452:login:Penguin
07/01/23 21:51:03 0oMO9Ojw
>>450
ハイブリッドハードディスク
URLﾘﾝｸ(www.google.co.jp)
どこにも8MB程度のRAMのキャッシュメモリの話はないですが
自分で確認してください
453:login:Penguin
07/01/23 22:17:31 xbr0LMQ0
>>452
DRAM のキャッシュと不揮発のキャッシュを
併用することになっている。
URLﾘﾝｸ(pc.watch.impress.co.jp)
454:login:Penguin
07/01/23 22:23:32 0oMO9Ojw
>>453
URLﾘﾝｸ(japanese.engadget.com)
ハードディスクドライブのバッファを大容量NANDフラッシュメモリに置きかえたハイブリッドHDD
455:login:Penguin
07/01/23 22:35:32 8K+SLyEi
開発者の発表スライドにengadgetの記事で反論する珍行動
456:login:Penguin
07/01/23 22:52:33 xbr0LMQ0
>>454
そうは言うが、Samsungのホワイトペーパーでも
First, Hybrid HDD has flash memory playing a supplementary
role to DRAM in order to dramatically reduce the boot time
and improve system capacity.
URLﾘﾝｸ(www.samsung.com)
とあるので、DRAMによるキャッシュも積んでいるんだと思う。
DRAM→NVRAMはいきなりの電源断でも書ききれるという意味で
データが失われないという仕組みは可能だと思うが、
DRAM無しというのは難しいんじゃないか？
そもそも上に出したWinHEC2006のスライドも元は
Samsungの描いた絵だし。
457:login:Penguin
07/01/23 23:51:46 0oMO9Ojw
>>456
>>453の図と>>456の図はほぼ同じなんだが、どちらの図にもI/O両方の矢印がある
この両方向でDRAMをスルーしてNVRAMにアクセスしている
ハイブリッドディスクはブート時に1-2KBのRAMにブートセクタをコピーするんだが、このDRAMキャッシュはその部分の事ではないのか？
>>456を翻訳しても、ズバリ、キャッシュに使っているというようには訳せないんだが
458:457
07/01/24 00:17:56 vzigmnXE
× NVRAM
○ NANDフラッシュメモリ
459:login:Penguin
07/01/24 00:38:31 uMM8sw+h
だから MRAM,FeRAM とかの高速不揮発メモリに
期待って話だったんじゃねーの?
460:login:Penguin
07/01/24 01:39:30 Wx+4qs1R
耐久年数と揮発/不揮発は関係あるの？
461:login:Penguin
07/01/24 02:19:19 OH8//z4U
耐久年数が多いと揮発しにくいので、一度書いたら
上書きがとても大変
462:login:Penguin
07/01/24 08:32:43 vzigmnXE
>>460
現行のフラッシュメモリは耐久年数は低いとされている
しかし、>459のMRAMは耐久年数のみならずスピード自体も揮発性メモリより高い
FeRAMもMRAMに準ずる
463:login:Penguin
07/01/24 15:27:52 fll6hQgJ
フラッシュメモリが高い耐久性を持ってなきゃいけない必要性はない。
ハミング符号なりで保護して不良部分を置き換える下のレイヤーを一
層設ければ耐久年数は無視できる問題ではないか?
464:login:Penguin
07/01/24 16:04:57 vzigmnXE
URLﾘﾝｸ(webleverage.jp)
Intel Macのマルチブートっておもしろいねえ
OSX用と全く同じ内容のMS-DOS用のパーティションテーブルを作ってるよ
465:login:Penguin
07/01/24 16:17:28 mEXlFMcS
>>463
そういうのも含めての耐久性じゃない？
466:login:Penguin
07/01/24 16:22:03 vzigmnXE
>>463
現状すでにやられてる話でしょ
467:login:Penguin
07/01/26 03:11:35 9ovjxSc8
現状でも、書き込み寿命の均一化はやってあるよ。
それでやっと今の寿命になってる。
個人的には、停電時にファイルを確実に守る方法は
UPS以外に有効な方法は無いと結論をだしてる。
468:login:Penguin
07/01/26 15:45:58 S6wJxTFd
確実な方法なんてないと知るところから全ては始まるんだがな。
# ようは何処まで守りたいか、という話
469:login:Penguin
07/01/26 21:20:42 LxxsiSqP
そういうこと
どこまで妥協できるかだね
470:login:Penguin
07/01/27 02:04:17 hzYyrGKz
俺は大切なデータは石に彫って埋めてる。
471:login:Penguin
07/01/27 06:38:54 E9E1wd6D
>>463
NAND型フラッシュメモリ
URLﾘﾝｸ(ja.wikipedia.org)
一般的なデータ書き込みおよび消去後、
不良ブロックの検知処理を行い、
不良ブロックを管理するロジックが組み込まれている。
．．．
各ブロックの書き込み消去回数が平均化するようにする手法が広く用いられている。
472:login:Penguin
07/01/27 09:08:22 u9/4vZC9
>470
ちゃんと3か国語位は並べておけよ
473:login:Penguin
07/01/27 09:57:51 4NCB46QC
Hans Reiser、近況
URLﾘﾝｸ(opentechpress.jp)
「Hansを陥れるための罠」を仕掛けたのは
ロシアのスパイ組織じゃなくてext4の中の人じゃないか？
474:login:Penguin
07/01/27 10:21:57 NEv34+KY
ロシアとはまた厄介な
475:login:Penguin
07/01/28 21:50:55 Znedwxfp
SDなんかだとうすっぺらいですが、あの中にそんなロジックが入ってい
るんですか? 知らんかっただけにちょっと驚き。
476:絶対☆妹至上主義
07/01/29 02:05:06 ncjfs3KH
>>471
NANDでも、何度でも書き込めるわけでは無いんだな
477:login:Penguin
07/01/29 02:33:50 dIKGkRrE
誰がうまいｋ（ｒｙ
478:login:Penguin
07/01/29 13:41:07 siKMYi/7
そのツッコミがなければボケの存在に気付かなかったよ。
479:login:Penguin
07/01/29 22:12:15 aMwlfPuf
>>475
それはデバイスドライバの仕事
480:login:Penguin
07/01/30 22:33:33 ysSJZIzG
ここならlusterやってる人いるかな
1.4系と1.6系があるんだが、どっち使ってる？
481: ◆IIiDC8JS7w
07/01/30 22:40:38 gRlPMLvw
今はLustre 1.6Beta7(2007/1/15付近にでたもの)
482:login:Penguin
07/01/30 23:07:08 ysSJZIzG
サンキュー>481
余ってるPCが4台ほどあるので、試しにluster組んでみるよ。
483:login:Penguin
07/02/01 12:33:57 AuhPSHSf
LinuxのVFSがダメだって何度もこのスレで見たけど、
具体的にどこがどのようにマズイの？
484:login:Penguin
07/02/01 12:40:05 z56kQWBE
syncを発行しているのに実際にディスクに書かない、と言うのが通説
(ちと古いか)。
485:login:Penguin
07/02/01 16:31:34 d0gGLI0t
>>484
最近のはFreeBSDもそうらしいね
486:login:Penguin
07/02/01 17:04:59 lF996rlo
(OSが)syncを発行して(書き込みOKもらって)いるのに実際に(HDDが)ディスクに書かない
487:login:Penguin
07/02/01 17:07:38 KD9t2gZH
1月版 ext3でデータが破損！？ メモリ管理で不整合
URLﾘﾝｸ(www.atmarkit.co.jp)
>Debian独自のパッチの影響
ZFS progress.
URLﾘﾝｸ(blogs.freebsdish.org)
>98% functionality is implemented and work.
488:login:Penguin
07/02/01 17:23:14 DApPY+KS
>>486
>>376でガイシュツ。あと、読み間違えてないか? 2.6.18ではDebianパッチの影響だけど、
2.6.19では標準のカーネルでも発生するぞ。
んで、ZFSはFUSEだから正直問題外。
489:login:Penguin
07/02/01 17:32:32 sGGvNr2g
誰も、2.6.19では起こらないといってないんじゃないかw
490:login:Penguin
07/02/01 17:35:04 RxKMsyN1
そもそも、ZFSなんてlinuxで使うやついないだろ
491:login:Penguin
07/02/01 17:38:25 lF996rlo
>using Linus' test-program the data corruption has been reported
>as far back as the 2.6.5 kernel. "It's not actually a new bug at all,"
URLﾘﾝｸ(kerneltrap.org)
実は2.6.5以降から問題は発生してたらすぃけど、どうなんでしょ。
それと486はSoftupdate vs Journalingの話かな、どっちかというと。
492:login:Penguin
07/02/01 18:04:36 z56kQWBE
>>491
問題はあったけど、2.6.19で表面化したと書いてあるだろう。
URLﾘﾝｸ(www.atmarkit.co.jp)
493:login:Penguin
07/02/01 18:15:01 9sgJPste
>>484
ATAだとwrite cache無効に設定しないとあんまり意味ないし。
# 一回デフォルト無効にしたら遅すぎるっていう苦情だらけで
# デフォルト有効に
SCSIは問題無し。
494:login:Penguin
07/02/01 18:16:32 9sgJPste
>>484じゃなくて、>>485だった。
495:login:Penguin
07/02/01 18:18:17 DApPY+KS
うが、>>486じゃなくて>>487だ。
>>489
>>487の書き方は誤解を招くような代物だったので。
>>490
NTFSの場合はデュアルブートの際やUSB HDDつなげた際に読み込めるというメリットが
あるけど、ZFSにはそういうメリットないものねぇ。きちんとkernel空間で実装して
ext4、JFS、XFSなどと同様に標準fsとして使えるようになっているのなら話は全然別だけど。
ZFSに関してはFreeBSDやOS Xにどうportされるのか注目かなぁ。
>>491
とりあえず、大きなファイルをmmap()するようなアプリを使う際は2.6.19.2に
しておいたほうがいいというのは確かかな。>>487の記事では2.6.20rc3以降なら
fixとは書いてあるけど、2.6.19.2でもfixされたことは書いていないのがアレだ…
496:login:Penguin
07/02/01 18:23:42 z56kQWBE
>>493
ファイルシステムの下には ATAやSCSIのディスクだけじゃなくて、
SAS,バッテリバックアップされたRAID,iSCSI,AoEなどなど
いろいろあるんですが、そのへんはどうなんすかね？
497:login:Penguin
07/02/01 18:31:16 DApPY+KS
>>496
各種デバイスの仕様と、そのデバドラのつくりによるとしか言いようがない。
SCSIやSATAだとFUAが使えるからデータをディスクへ書き込んだ時点で
終了通知をホストへ返すことができるわけだけど、デバドラがきちんと
作られていないのなら、デバイスレベルでFUAをサポートしていても
無意味なわけで。
498:login:Penguin
07/02/01 18:35:46 MMx52a8R
ストレージクラスなら、キャッシュへの書込みが終了した時点で返す。
もっとも、それは電源がちょっと落ちたところでキャッシュの中身が消えることがないようになっているわけだが。
499:login:Penguin
07/02/01 18:40:06 eaIr3GB1
>484 が言っているのは >486 のより手前の
OS に責任があるレイヤでの問題
ただし、結局その説が正しいのかどうかはよくわからん
500:login:Penguin
07/02/01 18:52:05 z56kQWBE
>>499
だから、そんなレベルでOSが責任をとってもデータがダメになる
ケースは多数あるわけで、それなら始めからベストエフォートに
してページキャッシュをいろいろ最適化したほうがマシ、というのが
Linuxの設計方針だろ。Linuxカーネル解読室とか読めよ。
501:login:Penguin
07/02/01 18:53:40 8hEfCwF0
>>499
このスレでも何回か出ている話題だけど、>>384-419あたりの議論でだいたいの結論がついてないか?
502:login:Penguin
07/02/01 20:50:11 n6dF5ODI
>>500
それはおかしくないか？
ユーザーによってニーズは違うだろう
スピードへの最適化と信頼性への最適化の２つの選択肢を与えるべきじゃないのか？
503:login:Penguin
07/02/01 21:04:29 8kIqyObB
Linuxカーネル解読室ってオライリーのunderstanding the linux kernel 3rd edition より良いの？
504:login:Penguin
07/02/01 22:04:54 bacTwvVC
>>501
長すぎるからサマライズキボン。
キチガイは伝染する？
>>502
信頼性欲しければ違う実装使えってことだろ。
それか自分で作るか。作ってもLinuxにはマージしてもらえない気がするが。
>>503
後者の2版和訳を読んだ限り上っ面の説明しかできていない。
前者は読み込んでないから知らぬ。
505:login:Penguin
07/02/02 02:15:32 LHpcI4XW
>500
そんなヌケサク説明を本気で信じてるの?
解決策にもなんにもなってないし...
506:login:Penguin
07/02/02 21:15:48 FrGCgZny
結局、まっとうな批判に対して「キチガイ」と罵ることしかできない
ということでFAか？
507:login:Penguin
07/02/02 21:24:00 zNdISUUI
はいはい
508:login:Penguin
07/02/02 21:28:42 T7lvryZy
いや、大したことのないレスにキチガイって返す方がおかしいよ
509:login:Penguin
07/02/03 03:37:04 kg/qeKbc
>>491
その情報が正しいとなると、RHEL4.5で修正入るのかな?
510:login:Penguin
07/02/03 14:58:47 5bzUz2co
とりあえず、504は放置しとけ
511:login:Penguin
07/02/04 12:40:11 SIrUcCus
XFSとext3とReiserFSだとどれが安全?
512:login:Penguin
07/02/04 12:43:34 I1zy8FgT
どれも危険極まりない。
お前が使えば。
513:login:Penguin
07/02/04 16:27:09 VendWddW
>>511
今からならReiserFSがいい。
状況は今がドン底。逆にこれ以上悪くなる心配がない。
後は這い上がるのみ。
514:login:Penguin
07/02/04 17:21:58 J2syga+J
>>511
つかちょっと上のレスも見らんないのお前は？
JFSだけはガチってのがこのスレの総意だろ。
515:login:Penguin
07/02/04 17:33:06 OnmEjYbp
ガチ、か…
516:login:Penguin
07/02/04 18:34:37 e+PaBkqY
スルーされ具合についてはガチだな
517:login:Penguin
07/02/04 18:38:09 KaQxELcg
今からならＲｅｉｓｅｒ４だろ
518:login:Penguin
07/02/04 18:41:31 OUXrG2xd
俺はせっせと Solaris に移行中
519:login:Penguin
07/02/04 22:08:15 SIrUcCus
JFSのトラブルの報告が無いのは誰も使っていないからだろ?
520:login:Penguin
07/02/04 22:10:05 /f4Jfrib
Yes, SIr!
521:login:Penguin
07/02/04 22:12:54 6B5J03Tx
使ってますが何か
522:login:Penguin
07/02/04 23:07:54 BkRpNHOD
>>521
お前だって、最悪飛んでもいいパーテーションでしか使ってないだろ。
523:login:Penguin
07/02/04 23:15:37 wTKNJ/kp
>>518
Solarisって使いやすさはどうなの？
パッケージ管理が簡単なのかどうかと、パッケージ数が豊富なのかどうかが気になる。
昔はGCC入れて、各種アプリを自前コンパイルしないといけない時代があったよね。
524:login:Penguin
07/02/04 23:24:50 I1zy8FgT
今も基本的にはそうだが。
Sunfreewareのビルドが気に入らなければ、自分で作るしかないから。
パッケージ管理そのものについても、RPMやdebほど洗練はされていない。
パッチとか当てると普通に設定ファイルを上書きしたりするから、注意がいる。
525:login:Penguin
07/02/04 23:34:10 9s1+/enK
JFS はハードディスクが壊れただけでファイルシステムがぐちゃぐちゃになったので糞。
あと、NLS でちゃんと変換出来ないファイル名のファイルを作るとロストするときがあったので糞(相当昔の話だが)。
526:login:Penguin
07/02/04 23:45:28 ScyYaqVx
> JFS はハードディスクが壊れただけでファイルシステムがぐちゃぐちゃになったので糞。
527:login:Penguin
07/02/04 23:53:20 l/38o1m3
ちゃんと書かないとつたわらないだろうな
528:login:Penguin
07/02/05 00:10:05 xJuCgkva
HDD が壊れても大丈夫な FS 欲しいなぁ
529:login:Penguin
07/02/05 00:11:54 yquMgini
>>528
ひょっとしてそれはギャグで言ってるいるのか？
530:login:Penguin
07/02/05 00:18:06 rnFpdWND
ネットワークファイルシステムならHDDに書かないから安心。
531:login:Penguin
07/02/05 00:21:47 BjEiAhlg
サーバ側のローカルファイルシステムが(略
532:login:Penguin
07/02/05 00:51:26 TwCWVt0g
ネットワーク上に不良パケットとして放流するファイルシステム。
寿命が尽きる前に再放流。
常にネットワーク上をさまようデータたち。
533:login:Penguin
07/02/05 00:57:12 3z2RfYJO
Winnyファイルシステムかよｗ
534:login:Penguin
07/02/05 01:06:37 ikYVMwPI
>533
セキュアさが技術的に担保されるなら大アリ。
というか、似たものは既にある。
535:login:Penguin
07/02/05 02:16:43 3k+6xyTA
XFS使い始めて、もう１年になるがこの間、FSごと壊れたのは
まだ３回しかないが、これは運が良かったのか?
536:login:Penguin
07/02/05 02:32:05 B8r6Q64G
3回も壊れてるとかチョーウケル。
537:login:Penguin
07/02/05 02:34:35 1UIejfif
HDDが壊れたんだよな？
538:login:Penguin
07/02/05 04:49:19 3k+6xyTA
>>535 のHDDは物理的には全然平気だった。
そのHDD、別のPCに入れてWindowsXPで
使っているけど、普通に動いている。
539:login:Penguin
07/02/05 07:08:06 FEECW1nx
チキンは俺は ext3
540:login:Penguin
07/02/05 11:36:52 dxgxznv4
一度 RAIDコントローラが発狂して全滅したことはあったけど、
8年間使っててext2|3,reiser3,xfs,jfsいずれも問題ないな。
もちろん適材適所だよ。
541:login:Penguin
07/02/05 16:16:34 1UIejfif
>>538
情報thx
3度もというと結構多い感じするけど、どういう状況でそうなったの？
電源プチとかブレーカー落ちたとかそういうH/Wまわりしか思い浮かばなかったんだけど
IRIXでXFS使ってたときはFS壊れたことっていうのが無かったので
542:login:Penguin
07/02/05 17:09:15 kXNVJxPh
IRIXも最初のころはFSに限らずしょぼいしょぼいといわれていたけどね！
543:login:Penguin
07/02/05 22:41:56 xJuCgkva
最後までショボイまま終わったと?
544:login:Penguin
07/02/06 23:35:16 wGCOby4y
Excelが同期書き込みを使っているように感じているのは俺だけなのだろうか？
545:login:Penguin
07/02/08 21:38:43 yfGJF1IC
Excelってそれどんなfs？
546:login:Penguin
07/02/08 21:49:46 xdYwexjj
NTFS
547:544
07/02/08 22:00:34 xdYwexjj
１．セーブアイコンをクリック
２．ハードディスクがガリガリいいはじめる
３．マウスポインタは砂時計表示に
４．ステータスバーの進捗状況が作業中を表示
５．ステータスバーの進捗状況が作業終了を表示
６．ハードディスクがガリガリ音が止まる
７．マウスポインタが通常に戻り、Excelに制御が戻る
いつもこのような状況なのでそう思っただけ
ちなみにハードディスクはパラレルATA
548:login:Penguin
07/02/08 22:09:56 9ICUpqjJ
>>547
最近はLinuxでもExcelが動くようになったんですね。
是非、方法を教示していただきたいのですが。
549:login:Penguin
07/02/08 22:14:14 yfGJF1IC
>>547
(・∀・)・・・・・・・・こ、これは・・・・
ゴメンいい釣られ方思いつかなかった
550:login:Penguin
07/02/08 22:22:51 xdYwexjj
>>548
>>549
Excelの例をだしたのは悪かった
言いたいことは一つで、パラレルATAが同期書き込み不可なのが
正しい根拠があるのか疑問をもっただけ
FUAがないだけでは根拠にならないから
551:login:Penguin
07/02/08 22:24:56 xI5jKKjE
有るし
552:login:Penguin
07/02/08 22:26:01 xdYwexjj
>>551
ソース希望
553:login:Penguin
07/02/08 22:38:19 xdYwexjj
ATA
URLﾘﾝｸ(community.osdev.info)
ちなみにここでATAのコマンドを調べると、
0xe7に
0xe7 No-Data FLUSH CACHE
これはPIO制御なのでUDMA時は発行できないのかもしれないが
0xe8 PIO-Write WRITE BUFFER
こういうのもあるんだが
554:login:Penguin
07/02/09 00:41:33 Zb41PA+h
>>548
wine
555:login:Penguin
07/02/10 23:48:20 DJ1EsE63
今日、USBメモリを挿入した瞬間OSがフリーズした。
リセットボタン押して再起動したら、ファイルが lost+found に
大量に送り込まれた... orz
ext3 お前もか...
FC6やめた方がいいかな?
556:login:Penguin
07/02/10 23:52:49 rfqyKqr7
pugya-
557:login:Penguin
07/02/11 00:34:30 LZDtKzf8
>>553 ディレクトリ操作中に電源を落とした場合の典型的な症状だ
と思うけど。まさかそういうのも含めて「ファイルシステムが壊れた」
とか言ってるの？
558:login:Penguin
07/02/11 00:47:04 ukTcRXps
＞USBメモリを挿入した瞬間OSがフリーズした。
が一番Linuxのダメさを表わしてるわな。
559:login:Penguin
07/02/11 00:52:07 CJAQk2DO
>>558
俺もその光景を目撃した経験があるな．．．
エンジニアが若いSEに必死で弁解してたよ
560:login:Penguin
07/02/11 01:01:56 3+IsEM3X
俺iPodをWindowsマシンに接続した瞬間にブルースクリーンになったことある。
同じマシンに入ってるLinuxではちゃんとiPod使えたのに。
で、そういうトラブルのときWindowsでは対処法を探すのが難しいんだよな。
561:login:Penguin
07/02/11 01:02:23 /aD5Y840
脳内で fs 障害が発生しているようで、ご愁傷様です。
562:login:Penguin
07/02/11 01:14:56 ukTcRXps
まあ、USBはChipが悪いのが原因てことも多いからな。
563:login:Penguin
07/02/11 11:24:35 t4TvBlHe
いきなりリセットかけたときの、ファイル or FS へのダメージに
関して言えば、最近はLinuxよりもWindowsの方が安全なように
思えるようになってきた。
564:login:Penguin
07/02/11 11:42:26 P7PjeCmr
>>563
今ごろ気付いたのかよ
565:login:Penguin
07/02/11 12:56:32 iSwVn+BM
>563-564
この間LinuxとWindowsをVMwareのゲストで動かしてる最中に停電でホストが落ちちゃって、
再起動後どっちのゲストも起動しなくなっちゃったんよ。
Linux(ext3)の方は仕方ないからシングルユーザモードで起動してfsckかけたんだけど、
Windows(NTFS)の場合は一体どうしたらよいか分からなくて、現在進行形で途方に暮れてる。
何度スキャンディスク掛けても復活しないし。
566:login:Penguin
07/02/11 13:28:42 OboOTrcF
pugera
567:login:Penguin
07/02/11 13:53:58 itbL0uDG
>>562
チップじゃなくて外付けの回路かもな。
ろくにテストも出来ない検査が駄目なのか、
検査基準を甘々にしなけりゃならない程、
ハード屋がだらしないのか知らんけど。
568:login:Penguin
07/02/11 18:05:38 4xgL+aKM
>>565
たまたまだろ
Linuxだって死ぬときゃ復活もクソも無い
569:login:Penguin
07/02/11 23:11:39 t4TvBlHe
うちの会社では最近では、逆に Windows鯖も置くようになってきた。
昔のようなLinuxに対する神話というか盲信がなくなってきたからね。
570:login:Penguin
07/02/11 23:23:04 4cTo2V09
>Linuxに対する神話
ナニソレ?
571:login:Penguin
07/02/11 23:53:13 t4TvBlHe
Linuxは安定している。Linuxは安全である。Linuxは高性能である。
Windowsはその逆、っていう話のことを言った。
572:login:Penguin
07/02/12 00:02:21 CJAQk2DO
>>571
確かにそういう神話はあった
Linux関係の雑誌は特にひどかった
とりあえず褒めておけば売れるだろうという姿勢がみえみえだった
573:login:Penguin
07/02/12 00:08:28 ehOYrnXS
Xを使うと、Linuxは非常に重かったが、Windows95はPentium160Mhz,32MBでサクサク動いた（不安定だが）
このあたりの事は一切ふれられず、Linuxは軽いと言われてた
かくいう漏れも信じていたが
574:login:Penguin
07/02/12 00:18:36 c1CrXUSo
そんなに性能あれば X 使ってもサクサク動くね。
575:login:Penguin
07/02/12 00:22:43 vlEBE2dx
なぜかSolaris鯖復活。x86版だけど。
576:login:Penguin
07/02/12 00:37:24 ehOYrnXS
>>574
実際使った事あるのか？
32MBのメモリじゃXはスワップしまくって実用に耐えなかった
サービス止めまくってウィンドウマネージャにAfterStepなどを使っても無理
topでメモリ使用量見るとXだけで100MBぐらい使ってた
Xを使わなければ快適だったよ
577:login:Penguin
07/02/12 00:47:48 pKQ9EzWP
>>576
AfterStepじゃだめだ、tvtwm(twmよりも何故か軽い) とかにしないと...
578:login:Penguin
07/02/12 00:50:45 HIG9qOky
はて？
うちのdebianくんは、KDE3.2をスタートした時点で、トータル100MBも使ってないけど。
しかも、SendmailやらApacheやらいろんなサーバが起動した状態で。
579:login:Penguin
07/02/12 00:53:19 ehOYrnXS
>>577
tvtwmは使わなかったがtwmは使ってみたよ
結果は全くだめ
問題はX自体のメモリ消費量なんだよ
> AfterStepじゃだめだ、tvtwm(twmよりも何故か軽い) とかにしないと...
こういう事言ってる事自体が重い証明だろ
580:login:Penguin
07/02/12 00:56:02 tKkO1evC
フォント読み込みすぎだったんじゃね。
あとtwmよりfvwmのほうが軽かったような。
581:login:Penguin
07/02/12 00:59:08 ehOYrnXS
>>578
> うちのdebianくんは、KDE3.2をスタートした時点で、トータル100MBも使ってないけど。
それは異常だよ
漏れは256MBのVine機を持ってるが、Xを使ってしばらくたつと必ずスワップする
俺もLinuxは好きだが、神話はうんざりだ
582:login:Penguin
07/02/12 00:59:32 gH4+PeS3
もうコンソールでいいよｗ
583:login:Penguin
07/02/12 01:02:56 pKQ9EzWP
でもFSが壊れるのは神話じゃなくて事実だよね。
VFSが安定しない限り、この状況は続く...
584:login:Penguin
07/02/12 02:21:48 ue41F/Co
昔 166MHz 32MB で X と windowmaker と emacs と kterm 同時に使ってたけど
普通に使えてたよ。XFree 3.x 時代ね。
さすがにネスケとか立ちあげる時は emacs 落とす必要があったけど。
ただ、その後 update していくなかで X はどんどん重くなっていったので、
最新の X 入れたりしたらさすがに32MBじゃ足りないんじゃないかな。
585:login:Penguin
07/02/12 02:36:22 CD7jXCIx
はて？
うちのUbuntuくんは、Gnome2.16.1をスタートした時点で、600MBも使ってないけど。
586:login:Penguin
07/02/12 02:47:55 xmU+xA4+
793876 tty1 SL Feb11 37:31 Xgl
88540 ? Ssl Feb11 4:19 java v2c
76460 ? Sl 02:35 0:21 fx2
食いすぎだよな。
Xgl単独で800Mってもうあふぉかと。
beryl再起動直後でも458780。
587:login:Penguin
07/02/12 02:50:36 ue41F/Co
>>581
スリープ中のバックグラウンドプロセスじゃないの？
588:login:Penguin
07/02/12 02:52:51 PeW+mj3q
サーバでGUI常時動かす時点でどうかしてる。
ところがwindowsはGUIにOSがくっついていてGUIを止めれない。
スレ本来のFSに注目すると、
windowsのFSが逝きにくいのは事実。
だけれども、書き込み時のバッファフラッシュが強烈に重い。
linuxはVFSの段階でアクセスを最適化しようとするので重くなりにくいが、
その反面電源落ちクラッシュしやすい。
589:login:Penguin
07/02/12 02:55:18 s17apHnG
昔のは本当に軽かったんだよ
最近のは Window Manager に何を使っても重い
長年 fvwm だったが beryl にしてエフェクト使いまくっても
その差が体感できなかった
590:login:Penguin
07/02/12 03:02:39 ehOYrnXS
>>584
実用に耐えなかったというのはあくまで自分の主観で、遅くても動いていたことは間違いない
これを使えると思うかどうかは、各自の主観によると思う
しかし、後でWindows95とデュアルブートにした際にWindows95の軽さに驚いた
実機で16MBでも快適動作するのを確認している
591:login:Penguin
07/02/12 10:54:39 m2mmtgAx
ここって何のスレ?
592:login:Penguin
07/02/12 11:10:27 dthoHvZf
Windows9x系はさすがに話にならんだろ。
しかしNT系になって実装もそうだけど、設計でもUNIXは抜いたと思う。
MSは実装だけでなくアーキテクチャ設計能力も高い。
特にサードパーティによる新デバイス対応やOS拡張ができるようにする
モジュール構造は実世界で揉まれてるだけあって先を行ってるし、
どのOSでも一番問題を起こすドライバ系の安定度を高めるための
検証フレームワーク整備や教育といった面でも抜かりない。FS面でもNTFSは
安定してること以上にマルチストリームとかトランザクション対応とか
新機軸を着実に導入してるし、ユーザランド側でもPowerShellとかWSHと
いった洗練された仕組みがここ１０年で着実に入ってる。
元ネタが○×でコピっただけとか厨が煩いことがあるけど、設計・実装は
NT登場以来驚異的に高くなってるし、そもそも他の会社が対抗できてない。
上から下まで、技術・非技術面までひっくるめて整備してくるMSのこの底力が
一番すごい。
正面からNTFSに対抗できる存在としてReiser4に超期待してたんだけど・・・
まあReiser4が駄目でもZFSとかFUSEとかGFSとか面白いものはたくさん
あるけど、MSは侮れんよ。
593:login:Penguin
07/02/12 13:19:52 pKQ9EzWP
Reiser4、漏れも期待していたけど、あの様子では主流にはなれないだろうな。
いろいろな意味で...
結局、Linuxカーネル開発者な連中は、Reiser4を闇に葬るんじゃないだろうか?
594:login:Penguin
07/02/12 13:56:34 1qjVTFhI
> ここって何のスレ?
top の出力眺める誰でも出来る仕事の人が、日頃妄想していることを書く場所。
595:login:Penguin
07/02/12 15:52:05 DZj/9zPx
>>593
確かにいい口実にはなったよな。
596:login:Penguin
07/02/12 16:33:24 ehOYrnXS
カーネル開発者たちはReiser4が独自IOルーチンを実装していることを非難してるが、
ReiserFS側が一方的に悪いとも思えないな
597:login:Penguin
07/02/12 16:36:32 V8V5NCDB
>Reiser4が独自IOルーチンを実装
XFSは良くてReiser4がダメな理由ってなんだろ？
598:login:Penguin
07/02/12 16:39:03 DZj/9zPx
>>597
開発者の性格
599:login:Penguin
07/02/12 16:39:15 ehOYrnXS
Hans Reiserが嫌われてるからだろ
600:login:Penguin
07/02/12 16:52:04 9DGMw6Vy
ユダヤの陰謀
601:login:Penguin
07/02/12 18:18:43 fU0muqJg
lustre1.6beta7を入れてみたのだが、OSTをmkfs.lustreしたあとmountするところで
カーネルパニックしてしまう。
beta7ちゃんと使えてる人いたら教えて下さい。
602:login:Penguin
07/02/13 04:46:11 IyOcykyK
しかし、Reiser4の開発者の性格がいくら悪くても、
漏れ的には、今まで一番トラブルの無かったファイルシステムが
ReiserFSなんだよな。
というぐらい今まで、LINUXのFSには酷い目にあっている。
603:login:Penguin
07/02/13 07:26:14 keBYA0IK
>>596
Linuxの悪口として、I/Oが腐っているというのはよく言われることだからね。
独自実装したくなるぐらいに腐っているというのを、Linux系の有名開発者自らが
実践しちゃったんだから、kernel開発者としては捨て置けなかったんだろうけど。
Hansを非難するよか、まともなI/Oを実装することに力を注いでほしかったね。
604:login:Penguin
07/02/13 08:40:14 WemlgHvo
具体的にI/Oのどの機能がよくないんだ？
605:login:Penguin
07/02/13 08:56:45 fVgYhrXm
reiser たんは、あれだよね
他のカーネル開発者への礼節が欠いてるんだよな
それで嫌われてる、確か
606:login:Penguin
07/02/13 08:58:49 0u58eKNV
URLﾘﾝｸ(bulk.fefe.de)
の
filesystem: Unix filesystem scalability benchmarks (Linux Kongress 2006)
は、単純なベンチとはいえFSでこんなに違うんだなーってのが分かるな。
reiser4が速すぎで、嫉妬心から嫌われる理由になるのも分かる(違
信頼性を定量的に測定できればいいのにね。
607:login:Penguin
07/02/13 09:03:38 /i03HF+s
詳しいことはよくわからないんだが、
ﾗｲｻﾞｰのｺｰﾄﾞにはassertﾏｸﾛがたくさん入ってたので、あるｶｰﾈﾙ開発者が「読みにくいから削除してくれ」と注文をつけたらしい。
ﾗｲｻﾞｰが「そんなこという奴は素人だ」と言い返したので、こじれたのだとか。
逸話が本当なら、ｶｰﾈﾙ開発者が素人なのは間違いないが、ﾗｲｻﾞｰももっといいかたがあっただろうにな。
608:login:Penguin
07/02/13 09:10:45 /i03HF+s
Reiser4はﾌｧｲﾙｼｽﾃﾑのｻｲｽﾞ変更に対応してないんだよな。
先日、変更が必要になってそのことに気付いた。
ﾃﾞｰﾀの引っ越しがめんどくさかったのでいまはﾊﾞｰｼﾞｮﾝ3を使ってる。
ところでevms使いこなしてるひといる？
なかなか思うようにならなくて苦労してるのだが、、
609:login:Penguin
07/02/13 09:11:22 M3BPWPHj
UNIXのファイルシステムは、みんなトロイのばっかだからな
ディスクアクセスがいま一番ボトルネックで
データベースとかのベンチだと、明らかな差が出てくる
データベースはできるだけオンメモリで動作させるのが鉄則で
できるだけディスクアクセス少なくするんだけど
それでも、ディスクアクセスは避けられない
LAMPがはやるのもわかる気がする
610:login:Penguin
07/02/13 09:34:49 58Yqf8Hg
最後の文との関連が意味不明
611:login:Penguin
07/02/13 09:36:06 fVgYhrXm
Gentooの創設者もいってたな
あんなとろいファイルシステム使ってたら、日がくれちゃうよってw
Gentooはコンパイルして、ディスクアクセス頻繁に行うから
612:login:Penguin
07/02/13 09:39:39 M3BPWPHj
GentooはReiserFS推奨なんだっけ?
613:login:Penguin
07/02/13 09:46:38 x7MyuWlT
URLﾘﾝｸ(www-06.ibm.com)
古いけど、ext2で2分かかっていた処理がReiserFSでは15秒で終わるって言ってる。
614:login:Penguin
07/02/13 09:46:54 Bu7+VNy+
パフォーマンスと引き換えにファイルロストというすばらしい特徴を備えているけどなorz
615:login:Penguin
07/02/13 09:52:40 s1yugE0P
2.6.10くらいからしか使ってないが、ファイルロストなんてないよ。
FUDイクナイ
616:login:Penguin
07/02/13 09:56:29 zEMqaX8A
>>615
その昔にはあったんだよ。俺も引っかかったが。
ファイルシステム全体が破損して復旧不可能になるという素晴らしいバグが。
Hans Reiserの件は抜きにしてもその時の記憶があって精神的に
reiserfsを使いたくないというユーザが数多くいたりする。
617:login:Penguin
07/02/13 10:09:51 fVgYhrXm
IBMはいつのまにこんな文章のせてたんだ
俺もReiser使ってみよ
618:login:Penguin
07/02/13 11:00:48 d9NUXbGG
kernel 2.2時代の話を蒸し返されてもねぇ
619:login:Penguin
07/02/13 12:30:28 +OHugGIQ
2.4だろ
620:login:Penguin
07/02/13 20:06:01 0ByefPAX
>>616
どこで聞き齧ってきたのか知らんが、過去に騒がれたのはバグじゃなくて互換性。
バージョン間の互換性が低くて、古いカーネルでマウントして壊す奴が大漁発生。
621:login:Penguin
07/02/13 20:24:40 zEMqaX8A
>>620
それは十二分に致命的なバグだろうに。
あとscpするとファイルシステムごとクラッシュする問題もあった。
622:login:Penguin
07/02/13 22:24:46 WemlgHvo
>>609
データベースでファイルシステムがボトルネックになる時は
raw モードを使うよね。製品ごとに呼び名は違うみたいだけど。
623:login:Penguin
07/02/13 22:28:53 mh7vvqPu
ぼくも raw モードでセックルしていまつ。
624:login:Penguin
07/02/13 22:30:04 WemlgHvo
>>607
アサーションはきちんと入れた方がいいよな。
プログラマーの意図を的確に表したアサーションはコメントに勝ることも多いし。
本当に必要なアサーションをさして、あるいは特定のアサーションを指さずに
全体的にアサーションが多めというだけでアサーション減らせって
指摘したならそいつの方が間違いだと思う。
実際にコードも読まずにこれ以上なんとも言えないけど。
625:login:Penguin
07/02/13 22:48:26 mh7vvqPu
> 実際にコードも読まずにこれ以上なんとも言えないけど。
あることないこと書いて炎上するほうが楽しくね？
626:login:Penguin
07/02/13 22:51:47 aW6CdUS7
ようするに全てはユダヤの陰謀ってことで
627:login:Penguin
07/02/13 23:33:59 IyOcykyK
Reiserの逮捕事件って、実はkernel開発者の陰謀だったりして。
628:login:Penguin
07/02/14 00:01:31 8Y630KZm
NovellがMicrosoftへの忠誠の証として人身御供にされた...とか。
もしかしてSCOのダールたんが暗躍してたり。
629: ◆IIiDC8JS7w
07/02/14 00:59:07 WbKlTUui
>>601
mds/mgsはちゃんとmountできてますか？
lustrekernelかなぁ？e2fsprogsは更新した？
例；(必要ならば--reformat付きでmkfs、fsnameをtestfsとした場合)
mkfs.lustre --fsname=testfs --mdt --mgs /dev/hda6
mount -t lustre /dev/hda6 /mnt/mdt
確認 cat /proc/fs/lustre/devices
○mgsノードを指定してmkfs
mkfs.lustre --fsname=testfs --ost --mgsnode=comp001@tcp0 /dev/hda7
mount -t lustre /dev/hda7 /mnt/test/ost0
○mgsノードでostが認識されているかどうかチェック
確認 cat /proc/fs/lustre/devices
lustre 1.6Beta7は設定も楽になったし、結構安定してきたと思うんだけどなぁ
動的追加もostのmountでできるし。。
lustreをNFSmountして使用する以外なら。。
630:login:Penguin
07/02/15 06:48:33 tOeafQO2
>>470
ヨーロッパの寺院とかに行ってみろ
墓標の上をみんな歩いてて、石の表面に彫られた文字も
磨り減って読めなくなってるから
631:login:Penguin
07/02/15 17:16:25 WROae+uz
ベトナムで鳴らした俺達ファイルシステム部隊は、濡れ衣を着せられ当局に逮捕されたが、
刑務所を脱出し、地下にもぐった。
しかし、地下でくすぶっているような俺達じゃあない。
筋さえ通ればフォーマット次第でなんでもやってのける命知らず、不可能を可能にし巨大なファイルを
貯蔵する、俺達、ファイルシステム野郎Ａチーム！
俺は、リーダーntfs。通称MS謹製。
大容量と耐障害性の名人。
俺のような高信頼性FSでなければ百戦錬磨のつわものどものリーダーは務まらん。
俺はext3。通称Linuxの落とし子。
自慢のジャーナリングに、UPSはみんなイチコロさ。
ハッタリかまして、大容量ファイルから大容量ボリュームまで、何でもそろえてみせるぜ。
私は、HFSX、通称マカー。
チームの紅一点。
相互互換は、美貌とAppleTalkで、お手のもの！
よおお待ちどう。俺様こそRaiserFS。通称クレイジーFS。
アクセス速度は天下一品！
飛ぶ？壊れる？だから何。
FAT32。通称DOSあがり。
ロングファイルネームの天才だ。リソースの少ないPDAでもブン殴ってみせらぁ。
でもOver2GBだけはかんべんな。
俺達は、道理の通らぬ世の中にあえて挑戦する。
頼りになる神出鬼没の、ファイルシステム野郎 Ａチーム！
助けを借りたいときは、いつでも言ってくれ。
632:login:Penguin
07/02/15 17:55:02 xfBVvXN9
元ネタ古いなぁ・・・
633:login:Penguin
07/02/15 18:47:57 OUJa5vmP
別にそれぞれキラリと光るキャラ設定があるわけじゃないし
634:login:Penguin
07/02/15 18:50:48 WROae+uz
だよね。
ジェネレータみつけて勢いにまかせて作ってやり場に困って投下しました。
ごめん。
635:login:Penguin
07/02/15 23:32:42 EOMAzg7P
まあいいんでないか。
636:login:Penguin
07/02/17 22:11:48 0e5NoIPn
あのさ、あのさ、今さらながら reiser さんの良からぬ話を知ったんだけどさ、
今、会社で管理してる ReiserFS なサーバーは、やっぱり次に再インストールでもする際に
ファイルシステムを変えたほうがいいと思う?
637:login:Penguin
07/02/17 22:29:13 Oo4vzhEt
まったく思わない。
638:login:Penguin
07/02/17 22:32:52 YLjvBpYU
ReiserFS 3.xは既に開発が終わり、カーネルにマージされてるから当面は問題はないでしょ
Reiser4はカーネルにマージされていないのでこれも問題ない
漏れは当面は様子を見る
639:login:Penguin
07/02/17 23:07:39 CxH4DkuK
＞ReiserFS 3.xは既に開発が終わり、
メンテされなくなったら、追い出されるよ。
640:login:Penguin
07/02/17 23:16:21 YLjvBpYU
いずれな
641:login:Penguin
07/02/17 23:16:24 KFSDQiDM
ext2はどうなんだ?
642:login:Penguin
07/02/17 23:20:17 YLjvBpYU
追い出されるのが、例えば数年後なら俺的には何の問題もない
開発がストップしていれば性能面の魅力も消えているだろうから
しかし、状況は流動的
643:login:Penguin
07/02/18 01:49:30 lw5RYTmu
ext2は fsckが死ぬ程遅いからなぁ。
644:login:Penguin
07/02/18 08:53:56 RRBoRWUE
Linux終ったな
645:login:Penguin
07/02/18 16:16:45 +2MIv5gi
ext2でいい用途なら、ext3でいいのでは？ >> 643
646:login:Penguin
07/02/18 16:24:16 x2PO8wq2
>>645
> ext2でいい用途なら、ext3でいいのでは？ >> 643
一長一短
ext3はext2より遅い
実際比べてみればわかるよ
647:login:Penguin
07/02/18 17:39:23 PPDNN+G1
xfs_fsrがあるから、xfsをえらぶ
648:login:Penguin
07/02/18 18:27:01 N9FxkNNy
>>646
外部ジャーナルでdata=journal
649:login:Penguin
07/02/18 18:32:23 UT3ERil/
速さが欲しけりゃtmpfs、ramfsでも使ってろって
650:646
07/02/18 18:44:04 x2PO8wq2
>>648-649
>645は
> ext2でいい用途なら
と発言してるんだが
651:login:Penguin
07/02/18 23:24:26 lw5RYTmu
正直なところ ext2 や ext3 よりは 速度面から考えたら
ReiserFSやらXFSやらの最新のFSを使いたいが、
結局、ext2 or 3 よりも安定性が低いんだよね。
652:login:Penguin
07/02/18 23:29:23 9TlqakwN
>>651
そんなことはない
653:login:Penguin
07/02/18 23:33:14 9TlqakwN
現時点に限ればReiserFSやXFSは安定性で勝っても劣ることはない
654:login:Penguin
07/02/18 23:43:45 QuRETY6G
Reiserが安定しなかったのは過去のこと、っていうのはわかる。
でも今ext2や3よりも安定しているのを求めている以上、
どういう理屈で、どの程度安定しているのかという情報は欲しい。
でないと水掛け論になりかねん。
655:login:Penguin
07/02/18 23:44:49 pYLNl7kF
xfsってもう十分実用になってるの？
数年前にreiserfs3で入れてからしばらく情報集めてなかったんだけど、
次に入れる時にext3に戻るかxfsにするかで迷ってる。
656:login:Penguin
07/02/19 00:24:37 assudzzV
>>654
> どういう理屈で、どの程度安定しているのかという情報は欲しい。
そんな事ができる人がどこにいますか？
私が言えるのは、自分の経験とこのスレの過去ログぐらい
ext2や3で被害にあう方が圧倒的に多い
>>655
十分実用になってます
657:login:Penguin
07/02/19 01:08:42 iBUqDm6A
xfs って、うちの会社のサーバーじゃオーバースペックな気がしてなぁ。
だからといって ext3 じゃトロいしなぁ。
というわけで、ReiserFS を使ってるんだよなぁ。
何だかなぁ……。
658:login:Penguin
07/02/19 01:29:24 97QHaRcu
>xfs って、うちの会社のサーバーじゃオーバースペックな気がしてなぁ。
これってどういう意味でしょう？
そのサーバーで使うには、負荷が高いという意味？(機械にとって)
その用途で使うには、機能が過剰という意味？(目的に対して)
それとも、管理が面倒すぎるっていう意味？(人にとって)
659:login:Penguin
07/02/19 01:38:10 l8ESTcsS
>>656
でもReiserで過去に失敗した人がReiserよりext、って言ってるわけでしょ。
それは>>620の問題があって、それに引っかかった人だと思うけど。
過去の経験を補強する情報がなければ結局水掛け論になるよ。
たとえばSunなんかはZFSの信頼性は99.9999……％云々っていってるけど、
ああいう形で信頼性を示せれば信頼性に関する議論も進むし、
そういう情報が欲しいといってるわけで。
（その信頼性を実現する仕組みに関する簡単な解説でもつけてくれればなおいい）
660:login:Penguin
07/02/19 01:57:51 jkHVDhT6
Sunの99.9999...なんてマーケットトークに決まってんじゃん。
実装バグで起きる問題の確率が事前予測できるわけない。
まあ、商用製品で正式採用する以上、テストパターンを網羅して
走らせるだろうから、最終的には上の信頼性だろうけど。
安全性設計の部分だけに評価して各FSを比較できないもんかなぁ。
あとは実装容易性の評価とか。
661:login:Penguin
07/02/19 02:18:24 HPwpnWaB
信頼性って評価難しいよなあ。
参考までに俺は各種サーバ(主にファイルサーバー)約10台
計約50TBを xfs で使ってる。信頼性に関していえば ext3 と比べてどっ
ちが良いかはよく分からない。性能など信頼性以外の面では xfs
が優れてだと思う。freeze もできるし。
話題の ZFS についても壊れるというのはまだ経験ないけど、ファイル
システム関連の操作が引き金になってOSが固まるとい現象はよくある。
今日も zfs destroy の最中に固まった。
662:login:Penguin
07/02/19 03:03:56 /3Lv0pp1
HDDの信頼性測定とかは1000台近くを何日か稼動させて
故障台数とポワソン分布で計算するんだってさ。よくわからんけど。
fsみたいな故障しにくいものを測定するにもそんなやり方でやるのかね？
663:login:Penguin
07/02/19 07:40:17 AMxoEq8N
>>662
それはMTBFあたりを出すときのやりかただろ？
664:login:Penguin
07/02/19 12:11:33 gCr74owG
ポワソン分布でなにかまずいのか?
665:login:Penguin
07/02/19 12:37:56 2Z7LmjBo
カイ2乗検定とかじゃないの？
666:login:Penguin
07/02/19 14:22:21 7bxVjLSa
最近、GoogleがHDDの故障率のレポだしてたけど
あれ各種ファイルシステムでレポ欲しいよなあ
667:login:Penguin
07/02/19 14:31:37 HPwpnWaB
ext2 の上に GFS (google file system)っていうのは昔の話？
668:656
07/02/19 17:03:47 PUnHazDt
>>659
要求しているのは、信頼性の定量評価でしょう
それなら、検証するための条件を実際に出してほしい
それは無理でしょう
669:login:Penguin
07/02/19 19:17:04 assudzzV
>>659
> でもReiserで過去に失敗した人がReiserよりext、って言ってるわけでしょ。
> それは>>620の問題があって、それに引っかかった人だと思うけど。
例えばこのReiserFSのバージョン間の互換性の問題。
これを信頼性の比較テストで見つける事は非常に難しい。
670:login:Penguin
07/02/19 19:21:43 2Z7LmjBo
へーそんなに互換性低いんだ。
Linux2.4の頃からずっと、reiserは3.6で止っていて大丈夫だと思ってた。
671:login:Penguin
07/02/19 19:32:34 S8QS6vkZ
3.5の時代だろ。
672:login:Penguin
07/02/19 19:39:45 assudzzV
>>670
2.2カーネル+ReiserFSパッチと2.4カーネルにマージされたReiserFSとの互換性
2.4カーネルでマウントできなかった
673:login:Penguin
07/02/19 19:50:01 2Z7LmjBo
なんだ、そんな昔の話かよ。
しかも、カーネルに統合されていない時代の話しだし。
674:login:Penguin
07/02/19 19:56:23 assudzzV
>>673
2.4カーネルは安定性に大きな問題があって、長期間に渡って2.2カーネルと併用されてた
675:login:Penguin
07/02/19 20:00:02 2Z7LmjBo
それは違うだろ。
はるか昔から、安定版、現行版、開発版という体系だったんだから。
676:login:Penguin
07/02/19 20:02:34 assudzzV
ディストリでの2.4の採用が大きく遅れたんだよ
677:login:Penguin
07/02/19 21:34:21 S8QS6vkZ
676のいうディストリを挙げてくれないか？
678:login:Penguin
07/02/19 22:08:11 assudzzV
カーネル2.4のリリースが2001年1月10日
SUSEはすぐに取り入れ2001年2月
Turbo Linuxは少し遅れ、2001年5月
Red Hatは1度2.4のリリースを見送り2001年9月
保守的な
Vine2002年4月
Debian2002年7月
679:login:Penguin
07/02/19 22:10:48 hoyrNl8c
2.4ではVMがなかなか安定しなかった希ガス。
Linusがファビョって途中でVM入れ替えてた希ガス。
680:login:Penguin
07/02/19 22:17:29 S8QS6vkZ
>>678
で、2.6の場合は？
681:login:Penguin
07/02/19 22:24:08 assudzzV
>>680
自分で調べてくれないか？
2.4は肝心のRed Hatがリリースを見送ったのが痛かったんだよ
682:login:Penguin
07/02/19 22:34:50 ccsrEDDl
ID:S8QS6vkZは典型的な知能障害の教えてくん。放置推奨。
683:login:Penguin
07/02/19 22:50:28 S8QS6vkZ
しゃーねーなー、一度だけだぞ。
2.6.0リリース: 2003/12
SUSE: 2004/3(2.6.4)
Turbo: 2003/10(2.6.0test5)
RHEL: 2005/2(2.6.9)
FC:2004/5(2.6.5)
Vine:2006/11(2.6.16)
Debian: 2007/?(2.6.18)
2.6と比較して、2.4が取り立てて遅れたとはいえない。
ディストリ＝レッドハットしか頭にない誰かさんには
けしからんかもしれんがね。
684:login:Penguin
07/02/19 23:06:46 assudzzV
> 2.6.0リリース: 2003/12
> SUSE: 2004/3(2.6.4)
> Turbo: 2003/10(2.6.0test5)
> FC:2004/5(2.6.5)
保守的なディストリ以外はすぐに入ってるじゃないか
685:login:Penguin
07/02/19 23:15:09 YjhinaPB
2.6 の方が断然採用が遅れてるのに目を向けられない ID:assudzzV
686:login:Penguin
07/02/19 23:15:54 WFcsg+zG
>>661
誰かファイルシステムの信頼性テストアプリ書いたら面白そうだね。
以下の処理をランダム（どのファイル／ディレクトリ、どの処理、何回）で実行。
作成するファイル名やディレクトリ名もランダム。
ファイル読込、ファイル書込、
ファイル作成、ファイル削除、ファイル移動、
ディレクトリ作成、ディレクトリ削除、ディレクトリ移動。
他にもメモリをぎりぎりまで使ってる状態でのテストや、
LoadAverageが10超えてる状態でのテストや、
上のテストを複数のボリュームに大して同時実行とかもやってみるといいかも。
687:login:Penguin
07/02/19 23:19:08 assudzzV
>>686
書き込み中の電源断は必須項目だよ
688:login:Penguin
07/02/19 23:52:06 iBUqDm6A
>>686
その仕様でｵﾏｲが書いてｸﾚ
689:login:Penguin
07/02/19 23:58:52 assudzzV
>>686
信頼性を「定量」するんだからな
ちゃんと何が起これば何点という重みもつけてくれよ
690:login:Penguin
07/02/20 00:46:37 xMR490Gf
>>668
６５４＝６５９＝俺。
６５４では定量評価と書いてないので納得してくれ。
定量評価が無理なのには同意する。
691:login:Penguin
07/02/20 01:06:30 dBqV9fZF
各ファイルシステムでランダム書き込みテスト中にシャットダウン。
これを１０万回位して有意な差があるかどうかで定量評価できない？
あとは実験ではなく書き込みアルゴリズム部分を抜き出して
相互比較するくらいか＞安全性の比較
692:login:Penguin
07/02/20 01:25:21 mknq5eEf
10万回って… 何年かける気だよ
693:login:Penguin
07/02/20 01:44:43 jhKEG9sP
>>691
教祖にでも頼んだら？
694:login:Penguin
07/02/20 01:59:56 RrNcxD36
>>687,691
電源断したら、10回に1回ぐらいでHDDが物理的に死ぬんじゃないかな。
昔UPS買う金もなかった頃、停電で5台のサーバ中1個ぐらいHDD壊れてたし。
695:login:Penguin
07/02/20 03:52:27 ER7Tw+jP
>>647
それは言える
696:login:Penguin
07/02/20 04:13:03 DkD2TaWO
Google File Systemってどんなの？
697:login:Penguin
07/02/20 10:01:01 lQlBrHwX
Gmailをバックエンドとしてマウントする、たんなるネタ。
698:login:Penguin
07/02/20 10:11:56 mknq5eEf
それgmailfs
699:login:Penguin
07/02/20 15:39:52 w1qTNq/E
まあ普通にやるならポア損だろう
700:login:Penguin
07/02/20 16:53:19 u7PVyFqb
>>696
つ[URLﾘﾝｸ(216.239.37.132)
ファイルシステムとしての機能は実装されているが、このスレで話題にするような
ものとはレイヤが違う希ガス
701:login:Penguin
07/02/20 17:04:16 mknq5eEf
「POSIX互換なファイルシステム総合スレ」にすればいいのかな。
702:login:Penguin
07/02/20 19:36:37 dgNADH13
>>694
> 電源断したら、10回に1回ぐらいでHDDが物理的に死ぬんじゃないかな。
何でそんなに死ぬんだ？
703:login:Penguin
07/02/20 19:47:27 /AXgYpgH
電源断が理由で起動できなくなった時に俺も物理的に壊れたと思ってた事があったｗ
704:login:Penguin
07/02/20 19:53:47 8d1pfd9r
むかーしのHDDは電源ぷっつんで、死んでたけどね。
705:login:Penguin
07/02/20 20:25:47 trVnBvGy
それは20MBのHDDの時代だろｗｗｗ
流石に、100MB超えたらヘッドの待避はしてるから。
706:login:Penguin
07/02/20 21:00:36 gPb9g80v
namesysでそんなテストやってなかった？
速度比較だけど内容はそんな感じだったよ。
しかし、一回でもエラーがあるようならﾌｧｲﾙｼｽﾃﾑとしては致命的だよね。
書き込み途中のﾃﾞｰﾀが電源断で失われるのは物理的に回避不可だからUPSなんかに頼るべきだけど、
それ以外のエラーはあってはいけないよね。
707:login:Penguin
07/02/20 21:25:48 RrNcxD36
>>702,704,705
40～80GBぐらいのHDDだったはず。
ひょっとしてかなり運が悪かったのかな？
708:login:Penguin
07/02/20 21:28:09 pQclaEp+
>>706
> 書き込み途中のﾃﾞｰﾀが電源断で失われるのは物理的に回避不可だからUPSなんかに頼るべきだけど、
> それ以外のエラーはあってはいけないよね。
ファイルシステムが逝く大きな原因の、書き込み中の電源断をテストから外したとする
そのテストで良い結果が出たら、信頼性のあるファイルシステムだと誰が思うんだ？
709:login:Penguin
07/02/20 21:28:56 PbWkwsqa
いぁ、家庭で使ってるようなあれで、HDDに書き込みしてないのがほぼ確認できた
時点で電源落としてればほとんど問題はないだろうし、サーバーで使ってて
いつ何をやってるのかよく分からない状態で電源が落ちればHDDやられるだろうし、
ケースバイケースなんじゃね?
710:login:Penguin
07/02/20 21:33:42 yxMMBa/L
/dev/sdX を read,writeするプログラムを書いて
電源斷すれば、ハードのせいかファイルシステムのせいか
はっきりするだろ？
711:login:Penguin
07/02/20 22:08:55 j2utBboh
書き込み中の電源断テストをしないで、いったい何をテストするのやら
712:login:Penguin
07/02/20 22:20:07 joRKZnqH
> 流石に、100MB超えたらヘッドの待避はしてるから。
根拠をきぼんぬ。
713:login:Penguin
07/02/20 22:27:21 ER7Tw+jP
電源断は本当に壊れたら困るから、IDE のケーブルを抜くってのは?
714:login:Penguin
07/02/20 22:31:41 pQclaEp+
ジャーナリングファイルシステム自体が
書き込み中の電源断に備えてジャーナルをせっせと書いているわけだろう
これをテストしないでファイルシステムの信頼性テストができるの？
715:login:Penguin
07/02/20 22:34:58 j2utBboh
そうそう
716:login:Penguin
07/02/20 22:40:09 8d1pfd9r
>>705
うん。ストップボタンがついてるやつな。
717:login:Penguin
07/02/20 23:02:15 RrNcxD36
>>714
なるほど。
ケーブル抜くとか物理的な方法だと何回もテストが大変だから、
強制アンマウントとかできないかな？
718:login:Penguin
07/02/20 23:10:14 dBqV9fZF
USBでアナログスイッチ制御してバスをいきなり切り離したりすれば
いいんじゃない？復帰させる時はバスつなぎ直してからモジュールを
リロード。
719:login:Penguin
07/02/21 01:22:44 WfQ7wulD
それだと既にHDDのキャッシュに入ってる分が安全に書き込まれてしまうかもしれない。
720:login:Penguin
07/02/21 02:39:41 n6EMsHwD
IDEのケーブル抜くのは、HDDのディスク面への傷はつかないかも知れないが、
インターフェイス部分を電気的に壊すかもしれないぞ。
それだったら、リセットボタンを押して強制リセットの方がハードウェア的に安全だと思う。
少なくとも強制リセットでXFSはFSが壊れたことがある。
721:login:Penguin
07/02/21 12:12:37 HkfANAOw
スループットなら iozone があるけど、
メタデータ部分に関するストレステストのようなものは
広く使われているものってあるかな？
722:login:Penguin
07/02/21 12:22:02 yYJCU+QD
まずは、ファイルシステムが壊れた、の定義からだな。
そうして話はループする。
723:login:Penguin
07/02/21 12:26:26 9eNEo15t
つーか書き込み中でもHDDのヘッドは浮いてますぜ。
724:login:Penguin
07/02/21 12:35:51 PCwOt2tc
IDEじゃダメなんじゃないの？
IDEはハード的に厳密な書込み保障してないんだろ？
725:login:Penguin
07/02/21 12:37:05 9eNEo15t
そのためのUPSだろ？
Linux鯖でシャットダウン用UPSなしはありえないだろ。常識的に考えて。
726:login:Penguin
07/02/21 12:38:32 AEAE1/jQ
ループしすぎ
727:login:Penguin
07/02/21 12:40:11 PCwOt2tc
LinuxはVFSが腐ってるから。
728:login:Penguin
07/02/21 12:41:14 2SjRgw4k
VFSって何？
729:login:Penguin
07/02/21 12:45:01 z+QDRw32
掃除のおばちゃんがUPSの後ろからサーバーのコンセントを引っこ抜いちゃった時を想定してテストするんだよ。
730:login:Penguin
07/02/21 12:46:34 5Xqck6zb
？？？
731:login:Penguin
07/02/21 14:26:01 Un3jNJTn
１他のﾌｧｲﾙ書込み処理中のﾄﾗﾌﾞﾙで既存ﾌｧｲﾙが壊れるのはﾌｧｲﾙｼｽﾃﾑの問題だが、
２書き込んでいる最中のﾃﾞｰﾀを保障する方法はないだろう？
ところで、１の状況になるような不出来ﾌｧｲﾙｼｽﾃﾑでは致命的だよね？
現実的におこる可能性のあるｴﾗｰと言えば、ﾋﾞｯﾄ抜けなどによるﾃﾞｰﾀｴﾗｰなんかだと思うのだが
ｴﾗｰ訂正機構などで回避するのがFSの役目じゃなかろうか。
ｴﾗｰ訂正できずひたすら読みなおすようではちょっとね。
732:login:Penguin
07/02/21 14:27:26 YuxiRYuL
?
733:login:Penguin
07/02/21 16:47:07 Gow8RfEW
>>724
> IDEじゃダメなんじゃないの？
> IDEはハード的に厳密な書込み保障してないんだろ？
>>553
734:login:Penguin
07/02/21 16:55:24 yYJCU+QD
$ nl linux/include/linux/ata.h |grep FLUSH
115 ATA_CMD_FLUSH = 0xE7,
116 ATA_CMD_FLUSH_EXT = 0xEA,
735:login:Penguin
07/02/21 16:57:27 Gow8RfEW
>>725
> そのためのUPSだろ？
> Linux鯖でシャットダウン用UPSなしはありえないだろ。常識的に考えて。
UPSおおいに結構
しかし、ジャーナルの話になる度にUPSの話を持ち出すのはやめてくれ
１．まずベースになるファイルシステムの信頼性を上げる
２．その上で更に安全性を確保するためUPSを使う
これが基本じゃないのか？
736:login:Penguin
07/02/21 17:21:02 PeRWIKib
ID:9eNEo15tみたいに根本的にわかってないヤシは放置しとけばいいのに
737:login:Penguin
07/02/21 18:23:37 GEUl/Slj
FS以前にVFSが腐ってるんだからUPS付けるしかないだろｗ
なんでも安いものには訳があるんだぜ
738:login:Penguin
07/02/21 18:27:39 Un3jNJTn
VFSってなに？
739:login:Penguin
07/02/21 18:43:51 DxVxbuVi
UPSをつけても治らない病気
740: ◆IIiDC8JS7w
07/02/21 18:49:35 HEsvAscu
xfsは独自のインタフェース等をもっていたけど、
VFSをベースにするように書き直す動きがでてきたようです。
URLﾘﾝｸ(marc.theaimsgroup.com)
741:login:Penguin
07/02/21 19:04:38 hD5S0IpV
>>738
聞く前にググろうぜー
URLﾘﾝｸ(ja.wikipedia.org)
URLﾘﾝｸ(www.atmarkit.co.jp)
しかしLinuxってVFS以外はかなり良いのに、VFSが大きく足を引っ張ってるよね。
高負荷時にIOwaitに取られて、パフォーマンスがた落ちするし(とくにext3)、
私の環境だとよくファイルシステムが壊れるし。
742:login:Penguin
07/02/21 19:08:36 HkfANAOw
「腐っている」と批判される VFS を改善する
という動きはないんですか？
といっても Linux は MPI 使ったシミュレーションと
LaTeX での物書きくらいにしか使っていないので
具体的にファイルIOが高負荷になったら
生じるという問題には遭遇したことがないのですが。
743:login:Penguin
07/02/21 19:32:46 Un3jNJTn
>>741
39s 理解が深まりました。
ところで>>742も書いてるけどVFSのどの辺が悪いの？
ｻﾝはﾌｧｲﾙｼｽﾃﾑまわりが良いとよくいわれるけど、実感したことがないんだよね。
直接比較しにくいから「体感速度」でしかないけれど。
744:login:Penguin
07/02/21 19:39:33 DxVxbuVi
気にならなければそのままでいいんじゃない？
745:login:Penguin
07/02/21 19:54:32 AEAE1/jQ
>>742
Linus「頑張りな」
746:login:Penguin
07/02/21 19:56:24 4ZGq/uco
UPS、UPSってループしすぎ
UPS使ったらFSの問題は修正する必要がなくなるのか？
747:login:Penguin
07/02/21 20:05:21 834Qq+xw
>>742
改善しようとして入る大きいバグよりは、
現状の踏む確率の低いバグの放置を選んでいる、と前スレで見た気がする。
>>746
んなわけない。
kernel(fs)の話なのにUPSを持ち出すほうがアホ。
748:login:Penguin
07/02/21 20:12:58 9eNEo15t
なんでUPS持ち出されると火病るんだよｗｗｗ
現状のKernelがしょぼいからHWでその穴埋めをしてるだけの話だろｗ
749:login:Penguin
07/02/21 20:15:34 yt14huen
kernelがしょぼいならNexenta使えばいいじゃない
750:login:Penguin
07/02/21 20:23:40 sObj1DzR
最近はFS<->DeviceDriverは、キャッシュフラッシュ機構を伴ったfs/deviceだとちゃんとフラッシュするようにしてるとオモタ。
user<->vfs<->fsはここが最近かつ長い論議になっているな
URLﾘﾝｸ(groups.google.com)
O_DIRECTっつーキャッシュを使わないフラグの話なんだが、O_SYNCとかもからんでくる。
rawデバイスへのIOなら意味はあるかもしれないけど、fsレベルだとkernelがする仕事いろいろあるのでどうかねぇって感じかね。
>>741
kernelとioスケジューラとmount option何?
751:login:Penguin
07/02/21 20:30:57 R1KNdqH1
低脳の俺じゃ話についていけん、離脱する。
752:login:Penguin
07/02/21 20:33:24 DxVxbuVi
>>748
穴埋めきれてないから
753:login:Penguin
07/02/21 20:40:25 9eNEo15t
>>752
BSDに転向しま～す
754:login:Penguin
07/02/21 20:55:45 yYJCU+QD
>>750
raw deviceにつづいてO_DIRECTも無くそうって話が確かその後にあったとおもう。
どちらも移植性以外にメリットがなく、O_DIRECTを使わないプロセスとの
キャッシュの整合性をとるのが難しくて、デバイス全体(/dev/sda)のopen時
くらいしか意味がなく、それだったらSG_IOつかえばいいじゃん、って話。
755:login:Penguin
07/02/21 21:06:53 hD5S0IpV
>>750
kernel 2.4.21-37.ELsmp
mount option は defaults,noatime
IOスケジューラはkernel 2.4だから選択不可
kernel 2.6ではまだ高負荷サーバの運用経験なし。
たぶん2.6にすれば、だいぶIOwait解消するとは思うけど。
756:login:Penguin
07/02/21 21:14:48 yYJCU+QD
(´-`).｡ｏO(2.4.20のリリースは2002/11/29....)
757:orz
07/02/21 21:15:32 yYJCU+QD
(´-`).｡ｏO(2.4.21のリリースは2003/06/13....)
758:login:Penguin
07/02/21 21:28:59 AEAE1/jQ
>>755
i ,､ n て'' ノノ ヾ !
i ﾉﾉノ ﾉ ノ ''´ ! /
j ' ´ ﾉ ( ヽ |
>-,, / ,,=━・!' ,ﾉ━＝= ! ﾉ だいぶIOwait解消するっていうレベルじゃねぇぞ！
!・ ヽ | ’ﾆﾝniii､ :::::i/ｨ7iii= i )
＼（てi iヽ ^' ~ -' /｝ URLﾘﾝｸ(osdn.jp)
｀i_ ､ ＼ i_ l_j
｀┐ i ／(,,, ,n 〉 /＼＼
￣￣へ ! ' T'' l | ＼
｜ ! i ン=ｪｪi) i ｿ )
| i´＼! ,, -ｪ｀､＿ﾝ ﾉノ 〈
| | ＼＼,, ｀―''´／/ |
759:login:Penguin
07/02/21 21:58:29 PCwOt2tc
syncもすっ飛ばしてしまえば、IOwaitなんて関係ないわなｗ
760:login:Penguin
07/02/21 22:08:11 hD5S0IpV
>>756-758
2.6にすればパフォーマンスが上がるというのは分かってるんだけど、
メンテで１時間止めるのも難しい状態だから、いつになったら2.6に差し替えられるのか…。
761:login:Penguin
07/02/21 23:02:44 BIoIhGtz
2.6.x になってもVFSの酷さは相変わらずだよな。