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

「書き込み順序にエレベーターシークアルゴリズム などを用いるので、
Journal ファイルへの >　Journal 記録の反映順序保証さえない」というのは
最近言わなくなって、その前の「sync システムコールを呼び出しても、
保証されない」というのを声高に主張するようになっているんだったかな。

syncしても書き込まれなのは事実だし。

あ、syncしても書き込まれないから、ジャーナリング不整合になるという結論は変化なしか。

で、その結論は正しいの？

奥なんとかさんに聞いとけ

最近のXFSはデータを準備してからメタデータを書くという噂を聞いたのだけど
ホント?

ext3のデフォと同じじゃん

BSDのsoftupdateもヤバくなるから取り下げたんじゃないのん？

>>394
ディスク側に持ってるキャッシュフラッシュのタイミングが気にいらん
ってな、話だっけ?

>>395
あと、FreeBSD 5.x以降ではLinux同様syncしてもflushされないのがわかったのもある

>>395
>　タイミングが気にいらん

そういう話じゃないだろう

ジャーナルに書き込んだがディスクはまだフラッシュしていない
この状態でクラッシュすると、OSはジャーナルを書き込んだと思っているが実際には書き込まれていない

あ、すまん
>395はソフトアップデートの話だったな
スルーしてくれ

キチガイって伝染するんだな

400

うん

ついでだが、>397の状態でも常に問題が起こらないとする
そうすると、ジャーナルは無用の長物だということにならないか？

問題では歩けど解決策が...ってことだろ

ヒント：再起動

まさに伝家の宝刀

ジャーナル破損→再起動→ファイルシステム破損
>>403-404

本当にどうも有難うございました

壊れるのは書き込みの順序が原因で、syncしないことは別問題

先生、質問！
１．書き込みの順序の問題が起こっているのはなぜですか？
２．syncしないことで起こる別問題って何ですか？

２は、データ自体が不正になってしまうことだな。
チェックポイント自体は正常に通過したけど、実際にデータが書き込まれていないってことだ。
チェックポイントを正常に通過しているから、ファイルシステム自体が壊れているわけではない。

これは、パフォーマンス上は有利であるが、非常に深刻な問題をもたらすことがある。

１は、媒体エラーによってもたらされるものだろう。
ジャーナルの再作成、fsckが必要になる。
lost+foundに前回のチェックポイント以降の更新データが保存される。

返事がないようなので、もうひとつ
３．自由なタイミングでsyncできても、書き込みの順序の問題は解決できませんか？

返事ぐらいしろよ

つまらないのでWindows2000の話

[書き込みキャッシュを有効にする] 機能を有効にすると、データが失われる
http://support.microsoft.com/kb/281672/

書き込みキャッシュが有効な場合の遅いディスク パフォーマンス
http://support.microsoft.com/kb/332023/ja

「この修正プログラムは、実装に伴うリスクのレベルを理解および承諾し、
適切なハードウェアの電源保護によってこのリスクを軽減できるという確信がない限り、
実装しないでください。」

書き込み順序の問題はディスクのcacheが原因
http://slashdot.jp/linux/article.pl?sid=02/09/18/0623254&mode=nested

>>２．syncしないことで起こる別問題って何ですか？
ディスクに確実に書き込まれたことを保証しないといけない場合に困る。
syncの呼び出し後にネットワークで書き込み終了を通知したが、
実際に書き込まれる前に電源が落ちるといったケースが考えられる

>>３．自由なタイミングでsyncできても、書き込みの順序の問題は解決できませんか？
syncによって順序を保証する手法もある。
詳細はlinux/Documentation/block/barrier.txtを参照。
但し、処理によっては実用にならない程遅い可能性もある。

>>412
>　>>３．自由なタイミングでsyncできても、書き込みの順序の問題は解決できませんか？
>　syncによって順序を保証する手法もある。

実はここが聞きたかったわけで、そうすると
>>406
>　壊れるのは書き込みの順序が原因で、syncしないことは別問題
別問題とは言えないことを自ら返事されたわけです

>>413
確かにそうだけど…
softupdateなんかで依存の発生する場所全部にsyncを入れるのが
現実的？非現実的である証拠のデータが出せなくて申し訳ない
ですが…

いえ、データ出すのは大変ですから
Windows2000でさえ両方の含みを残している
難しい判断なんでしょうね

ついでに、これも転載
http://lists.freebsd.org/pipermail/freebsd-stable/2006-September/028251.html

>>416
そのスレを読んでいくと、ジャーナリングでもsoftupdate同様に
todays desktop drives can lie about writing data.
の影響を受けるっていう、このスレの流れと同様の話になっていっていますな。

ハードディスクが独自に高性能化を辿った結果、
書き込み順についてはどんなに直接sync命令しても確実に保証されるものではないってことかな?

今のhddじゃエレベーターシークアルゴリズムとかは意味がないか逆効果かもとどっかで見たことあるし。

>>418
SCSIとSerial ATA 2.5はFUAによってwrite cache有効時でも書きこみの完了を保証できる。
ので、ドライバがまともに実装されていればOK。
ATAはcache flushを保証する手段が用意されていないので何をやっても無理。

ZFSではwc対策はどうなっているの？

しかし、ジャーナリングファイルシステムって、電源断とかのトラブルでも
ファイルが壊れないようにするものじゃないのか。

実験室での使用なので、けっこう動作環境が良くないのは分かるけど
今日、ext3 また壊れてしまった。フォーマットからやりなおし。
土曜にバックアップとっていて良かった。
やっぱりXFSに移行するかな。

ext3が何度も壊れ、
reiserfsの大パーティションのマウントの遅さが嫌になり、
XFSに行き着いて幸せになった俺

たしかに reiserfs はでかいパーティションのマウントに時間がかかるね

ちょっと気になったのは、このスレの過去ログ読むとLinuxのVFSのせいで
XFSでもファイルシステムが壊れるって聞いたけど、どうなの?

XFSはファイルシステムが壊れるよ

ext3はファイルは守ってくれないが
ファイルシステムは守ってくれるので
まだ安心

それじゃ、ダメじゃん。

ZFS to the FUSE
まだα版だけど。。
つ ttp://developer.berlios.de/projects/zfs-fuse/

まぁいろいろ悩む前にUPS買えってことで。
あとは日々のバックアップ。

FUSEじゃ読み書きできますよっていう程度で、本格的に使うのには
全然向かないな…

GFS使ってる人、手ageて。

デスクトップでJFS使い始めました。
前はReiserFSでした。
今のところ無問題。

>>421
どんなFSでも、ジャーナルにしてもRAIDにしてもファイルが壊れない
(壊れ難い)という認識は止めたほうが安全。
復旧を早くする方法論と割切ったほうがいい。
大切なデータはきちんとバックアップすること。

>>431
毎日cvsでgcc取ってきてビルドしてみて。
漏れは3年前emacsでそれやってたらfs壊した(XFS)。

XFS ってそんなに弱い子なのか。

gentooでほぼ毎日何かしらをコンパイルしたり、
時々動画をエンコしたり、
毎日えろまんがを読み漁っていますが、
XFSは元気です。

ファイルシステムを何にしてもHDDガリガリさせるのは
寿命を縮めるだけだから、できることならあまりやりたくないね。

>>436
それじゃlocateが動くLinuxは使えんがな。

locate は使えば便利なんだけど
知らない人とか使わない人にとっては負荷が無駄過ぎるな。
デフォルトで動くディストリも結構あるんじゃないの。

HDDの代わりにi-RAMとかフラッシュディスクを使えば解決

ガリガリ使えばHDDよりフラッシュのほうが寿命短いんじゃないの？

そこでMRAMとか相変化RAMとかですよ！

HDD の寿命とか気にしてたらまともに使えんだろう

フラッシュの方が圧倒的に短いわなｗ

ハイブリッドハードディスク楽しみだよねえ。っと。
http://www.itmedia.co.jp/news/articles/0504/26/news018.html

# スレ違い。

<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

http://www.die.net/doc/linux/man/man8/mkswap.8.html
　　For kernels after 2.3.3 there is no such limitation

http://www.die.net/doc/linux/man/man8/mkfs.xfs.8.html
　　the maximum size is just under 1 TiB.

FUA 関係なくデータのロストが防げるなら
フラッシュは大歓迎なんだけど、
そういう目的じゃないようなので
Intel の Robson でいい気もする。

>>446
>　FUA 関係なくデータのロストが防げるなら

ハイブリッドディスクはデータロストしないんじゃねぇ？
ライトキャッシュが不揮発性というのは大きいと思うんだが

もちろん、ソフト側が正しく制御する前提だけど

フラッシュメモリってライトキャッシュに使えるほど
書き込み耐久性あるの？

フラッシュに入る前にも当然8MB程度の
RAMがキャッシュメモリとして確保されていると思われ。
なのでその部分はやはり揮発すると思う。

>>450
揮発するといってもトランザクションを実行するくらいの
コンデンサ容量は確保されてるでしょ・・・・

>>450
ハイブリッドハードディスク
http://www.google.co.jp/search?hl=ja&q=%E3%83%8F%E3%82%A4%E3%83%96%E3%83%AA%E3%83%83%E3%83%89%E3%83%8F%E3%83%BC%E3%83%89%E3%83%87%E3%82%A3%E3%82%B9%E3%82%AF&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=

どこにも8MB程度のRAMのキャッシュメモリの話はないですが
自分で確認してください

>>452
DRAM のキャッシュと不揮発のキャッシュを
併用することになっている。
http://pc.watch.impress.co.jp/docs/2006/0526/hot428_01.jpg

>>453
http://japanese.engadget.com/2006/05/08/hybrid-hdd/
ハードディスクドライブのバッファを大容量NANDフラッシュメモリに置きかえたハイブリッドHDD

開発者の発表スライドにengadgetの記事で反論する珍行動

>>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.
http://www.samsung.com/Products/HardDiskDrive/whitepapers/WhitePaper_12.htm

とあるので、DRAMによるキャッシュも積んでいるんだと思う。
DRAM→NVRAMはいきなりの電源断でも書ききれるという意味で
データが失われないという仕組みは可能だと思うが、
DRAM無しというのは難しいんじゃないか？
そもそも上に出したWinHEC2006のスライドも元は
Samsungの描いた絵だし。

>>456
>>453の図と>>456の図はほぼ同じなんだが、どちらの図にもI/O両方の矢印がある
この両方向でDRAMをスルーしてNVRAMにアクセスしている
ハイブリッドディスクはブート時に1-2KBのRAMにブートセクタをコピーするんだが、このDRAMキャッシュはその部分の事ではないのか？
>>456を翻訳しても、ズバリ、キャッシュに使っているというようには訳せないんだが

×　NVRAM
○　NANDフラッシュメモリ

だから MRAM,FeRAM とかの高速不揮発メモリに
期待って話だったんじゃねーの?

耐久年数と揮発/不揮発は関係あるの？

耐久年数が多いと揮発しにくいので、一度書いたら
上書きがとても大変

>>460
現行のフラッシュメモリは耐久年数は低いとされている
しかし、>459のMRAMは耐久年数のみならずスピード自体も揮発性メモリより高い
FeRAMもMRAMに準ずる

フラッシュメモリが高い耐久性を持ってなきゃいけない必要性はない。
ハミング符号なりで保護して不良部分を置き換える下のレイヤーを一
層設ければ耐久年数は無視できる問題ではないか?

http://webleverage.jp/xen/wiki/index.php?howto#m6961cbc

Intel Macのマルチブートっておもしろいねえ
OSX用と全く同じ内容のMS-DOS用のパーティションテーブルを作ってるよ

>>463
そういうのも含めての耐久性じゃない？

>>463
現状すでにやられてる話でしょ

現状でも、書き込み寿命の均一化はやってあるよ。
それでやっと今の寿命になってる。

個人的には、停電時にファイルを確実に守る方法は
UPS以外に有効な方法は無いと結論をだしてる。

確実な方法なんてないと知るところから全ては始まるんだがな。

# ようは何処まで守りたいか、という話

そういうこと
どこまで妥協できるかだね

俺は大切なデータは石に彫って埋めてる。

>>463
NAND型フラッシュメモリ
http://ja.wikipedia.org/wiki/NAND%E5%9E%8B%E3%83%95%E3%83%A9%E3%83%83%E3%82%B7%E3%83%A5%E3%83%A1%E3%83%A2%E3%83%AA

一般的なデータ書き込みおよび消去後、
不良ブロックの検知処理を行い、
不良ブロックを管理するロジックが組み込まれている。
．．．
各ブロックの書き込み消去回数が平均化するようにする手法が広く用いられている。

>470
ちゃんと3か国語位は並べておけよ

Hans Reiser、近況

ttp://opentechpress.jp/~sado/journal/432?from=rss

「Hansを陥れるための罠」を仕掛けたのは
ロシアのスパイ組織じゃなくてext4の中の人じゃないか？

ロシアとはまた厄介な

SDなんかだとうすっぺらいですが、あの中にそんなロジックが入ってい
るんですか? 知らんかっただけにちょっと驚き。

>>471
NANDでも、何度でも書き込めるわけでは無いんだな

誰がうまいｋ（ｒｙ

そのツッコミがなければボケの存在に気付かなかったよ。

>>475
それはデバイスドライバの仕事

ここならlusterやってる人いるかな
1.4系と1.6系があるんだが、どっち使ってる？

今はLustre 1.6Beta7(2007/1/15付近にでたもの)

サンキュー>481
余ってるPCが4台ほどあるので、試しにluster組んでみるよ。

LinuxのVFSがダメだって何度もこのスレで見たけど、
具体的にどこがどのようにマズイの？

syncを発行しているのに実際にディスクに書かない、と言うのが通説
(ちと古いか)。

>>484
最近のはFreeBSDもそうらしいね

(OSが)syncを発行して(書き込みOKもらって)いるのに実際に(HDDが)ディスクに書かない

1月版　ext3でデータが破損！？ メモリ管理で不整合
http://www.atmarkit.co.jp/flinux/rensai/watch2007/watch01b.html
>Debian独自のパッチの影響

ZFS progress.
http://blogs.freebsdish.org/pjd/2007/01/28/zfs-progress/
>98% functionality is implemented and work.

>>486
>>376でガイシュツ。あと、読み間違えてないか? 2.6.18ではDebianパッチの影響だけど、
2.6.19では標準のカーネルでも発生するぞ。

んで、ZFSはFUSEだから正直問題外。

誰も、2.6.19では起こらないといってないんじゃないかw

そもそも、ZFSなんてlinuxで使うやついないだろ

>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,"
http://kerneltrap.org/node/7517
実は2.6.5以降から問題は発生してたらすぃけど、どうなんでしょ。

それと486はSoftupdate vs Journalingの話かな、どっちかというと。

>>491
問題はあったけど、2.6.19で表面化したと書いてあるだろう。
http://www.atmarkit.co.jp/flinux/rensai/watch2007/watch01a.html

>>484
ATAだとwrite cache無効に設定しないとあんまり意味ないし。
# 一回デフォルト無効にしたら遅すぎるっていう苦情だらけで
# デフォルト有効に
SCSIは問題無し。

>>484じゃなくて、>>485だった。

うが、>>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されたことは書いていないのがアレだ…

>>493
ファイルシステムの下には ATAやSCSIのディスクだけじゃなくて、
SAS,バッテリバックアップされたRAID,iSCSI,AoEなどなど
いろいろあるんですが、そのへんはどうなんすかね？

>>496
各種デバイスの仕様と、そのデバドラのつくりによるとしか言いようがない。

SCSIやSATAだとFUAが使えるからデータをディスクへ書き込んだ時点で
終了通知をホストへ返すことができるわけだけど、デバドラがきちんと
作られていないのなら、デバイスレベルでFUAをサポートしていても
無意味なわけで。

ストレージクラスなら、キャッシュへの書込みが終了した時点で返す。
もっとも、それは電源がちょっと落ちたところでキャッシュの中身が消えることがないようになっているわけだが。

>484 が言っているのは >486 のより手前の
OS に責任があるレイヤでの問題

ただし、結局その説が正しいのかどうかはよくわからん

>>499
だから、そんなレベルでOSが責任をとってもデータがダメになる
ケースは多数あるわけで、それなら始めからベストエフォートに
してページキャッシュをいろいろ最適化したほうがマシ、というのが
Linuxの設計方針だろ。Linuxカーネル解読室とか読めよ。

>>499
このスレでも何回か出ている話題だけど、>>384-419あたりの議論でだいたいの結論がついてないか?

>>500
それはおかしくないか？
ユーザーによってニーズは違うだろう
スピードへの最適化と信頼性への最適化の２つの選択肢を与えるべきじゃないのか？

Linuxカーネル解読室ってオライリーのunderstanding the linux kernel 3rd edition より良いの？

>>501
長すぎるからサマライズキボン。
キチガイは伝染する？

>>502
信頼性欲しければ違う実装使えってことだろ。
それか自分で作るか。作ってもLinuxにはマージしてもらえない気がするが。

>>503
後者の2版和訳を読んだ限り上っ面の説明しかできていない。
前者は読み込んでないから知らぬ。

>500
そんなヌケサク説明を本気で信じてるの?

解決策にもなんにもなってないし...

結局、まっとうな批判に対して「キチガイ」と罵ることしかできない
ということでFAか？

はいはい

いや、大したことのないレスにキチガイって返す方がおかしいよ

>>491
その情報が正しいとなると、RHEL4.5で修正入るのかな?

とりあえず、504は放置しとけ

XFSとext3とReiserFSだとどれが安全?

どれも危険極まりない。
お前が使えば。

>>511
今からならReiserFSがいい。
状況は今がドン底。逆にこれ以上悪くなる心配がない。
後は這い上がるのみ。

>>511
つかちょっと上のレスも見らんないのお前は？

JFSだけはガチってのがこのスレの総意だろ。

ガチ、か…

スルーされ具合についてはガチだな

今からならＲｅｉｓｅｒ４だろ

俺はせっせと Solaris に移行中

JFSのトラブルの報告が無いのは誰も使っていないからだろ?

Yes, SIr!

使ってますが何か

>>521
お前だって、最悪飛んでもいいパーテーションでしか使ってないだろ。

>>518
Solarisって使いやすさはどうなの？
パッケージ管理が簡単なのかどうかと、パッケージ数が豊富なのかどうかが気になる。
昔はGCC入れて、各種アプリを自前コンパイルしないといけない時代があったよね。

今も基本的にはそうだが。
Sunfreewareのビルドが気に入らなければ、自分で作るしかないから。
パッケージ管理そのものについても、RPMやdebほど洗練はされていない。
パッチとか当てると普通に設定ファイルを上書きしたりするから、注意がいる。

JFS はハードディスクが壊れただけでファイルシステムがぐちゃぐちゃになったので糞。
あと、NLS でちゃんと変換出来ないファイル名のファイルを作るとロストするときがあったので糞(相当昔の話だが)。

> JFS はハードディスクが壊れただけでファイルシステムがぐちゃぐちゃになったので糞。

ちゃんと書かないとつたわらないだろうな

HDD が壊れても大丈夫な FS 欲しいなぁ

>>528
ひょっとしてそれはギャグで言ってるいるのか？

ネットワークファイルシステムならHDDに書かないから安心。

サーバ側のローカルファイルシステムが(略

ネットワーク上に不良パケットとして放流するファイルシステム。
寿命が尽きる前に再放流。
常にネットワーク上をさまようデータたち。

Winnyファイルシステムかよｗ

>533
セキュアさが技術的に担保されるなら大アリ。
というか、似たものは既にある。

XFS使い始めて、もう１年になるがこの間、FSごと壊れたのは
まだ３回しかないが、これは運が良かったのか?

3回も壊れてるとかチョーウケル。

HDDが壊れたんだよな？

>>535 のHDDは物理的には全然平気だった。

そのHDD、別のPCに入れてWindowsXPで
使っているけど、普通に動いている。

チキンは俺は ext3

一度 RAIDコントローラが発狂して全滅したことはあったけど、
8年間使っててext2|3,reiser3,xfs,jfsいずれも問題ないな。
もちろん適材適所だよ。

>>538
情報thx
3度もというと結構多い感じするけど、どういう状況でそうなったの？
電源プチとかブレーカー落ちたとかそういうH/Wまわりしか思い浮かばなかったんだけど
IRIXでXFS使ってたときはFS壊れたことっていうのが無かったので

IRIXも最初のころはFSに限らずしょぼいしょぼいといわれていたけどね！

最後までショボイまま終わったと?

Excelが同期書き込みを使っているように感じているのは俺だけなのだろうか？

Excelってそれどんなfs？

NTFS

１．セーブアイコンをクリック
２．ハードディスクがガリガリいいはじめる
３．マウスポインタは砂時計表示に
４．ステータスバーの進捗状況が作業中を表示
５．ステータスバーの進捗状況が作業終了を表示
６．ハードディスクがガリガリ音が止まる
７．マウスポインタが通常に戻り、Excelに制御が戻る

いつもこのような状況なのでそう思っただけ
ちなみにハードディスクはパラレルATA

>>547
最近はLinuxでもExcelが動くようになったんですね。
是非、方法を教示していただきたいのですが。

>>547
(・∀・)・・・・・・・・こ、これは・・・・

　　　　　　　　　　　　　　　　　ゴメンいい釣られ方思いつかなかった

>>548
>>549
Excelの例をだしたのは悪かった

言いたいことは一つで、パラレルATAが同期書き込み不可なのが
正しい根拠があるのか疑問をもっただけ
FUAがないだけでは根拠にならないから

有るし

>>551
ソース希望

ATA
http://community.osdev.info/index.php?ATA

ちなみにここでATAのコマンドを調べると、

0xe7に
0xe7 No-Data FLUSH CACHE

これはPIO制御なのでUDMA時は発行できないのかもしれないが
0xe8 PIO-Write WRITE BUFFER

こういうのもあるんだが

>>548
wine

今日、USBメモリを挿入した瞬間OSがフリーズした。
リセットボタン押して再起動したら、ファイルが lost+found に
大量に送り込まれた... orz
ext3 お前もか...

FC6やめた方がいいかな?

pugya-

>>553 ディレクトリ操作中に電源を落とした場合の典型的な症状だ
と思うけど。まさかそういうのも含めて「ファイルシステムが壊れた」
とか言ってるの？

＞USBメモリを挿入した瞬間OSがフリーズした。
が一番Linuxのダメさを表わしてるわな。

>>558
俺もその光景を目撃した経験があるな．．．
エンジニアが若いSEに必死で弁解してたよ

俺iPodをWindowsマシンに接続した瞬間にブルースクリーンになったことある。
同じマシンに入ってるLinuxではちゃんとiPod使えたのに。
で、そういうトラブルのときWindowsでは対処法を探すのが難しいんだよな。

脳内で fs 障害が発生しているようで、ご愁傷様です。

まあ、USBはChipが悪いのが原因てことも多いからな。

いきなりリセットかけたときの、ファイル or FS へのダメージに
関して言えば、最近はLinuxよりもWindowsの方が安全なように
思えるようになってきた。

>>563
今ごろ気付いたのかよ

>563-564
この間LinuxとWindowsをVMwareのゲストで動かしてる最中に停電でホストが落ちちゃって、
再起動後どっちのゲストも起動しなくなっちゃったんよ。

Linux(ext3)の方は仕方ないからシングルユーザモードで起動してfsckかけたんだけど、
Windows(NTFS)の場合は一体どうしたらよいか分からなくて、現在進行形で途方に暮れてる。
何度スキャンディスク掛けても復活しないし。

pugera

>>562
チップじゃなくて外付けの回路かもな。
ろくにテストも出来ない検査が駄目なのか、
検査基準を甘々にしなけりゃならない程、
ハード屋がだらしないのか知らんけど。

>>565
たまたまだろ
Linuxだって死ぬときゃ復活もクソも無い

うちの会社では最近では、逆に Windows鯖も置くようになってきた。
昔のようなLinuxに対する神話というか盲信がなくなってきたからね。

>Linuxに対する神話

ナニソレ?

Linuxは安定している。Linuxは安全である。Linuxは高性能である。
Windowsはその逆、っていう話のことを言った。

>>571
確かにそういう神話はあった
Linux関係の雑誌は特にひどかった
とりあえず褒めておけば売れるだろうという姿勢がみえみえだった

Xを使うと、Linuxは非常に重かったが、Windows95はPentium160Mhz,32MBでサクサク動いた（不安定だが）
このあたりの事は一切ふれられず、Linuxは軽いと言われてた
かくいう漏れも信じていたが

そんなに性能あれば X 使ってもサクサク動くね。

なぜかSolaris鯖復活。x86版だけど。

>>574
実際使った事あるのか？

32MBのメモリじゃXはスワップしまくって実用に耐えなかった
サービス止めまくってウィンドウマネージャにAfterStepなどを使っても無理
topでメモリ使用量見るとXだけで100MBぐらい使ってた
Xを使わなければ快適だったよ

>>576
AfterStepじゃだめだ、tvtwm(twmよりも何故か軽い) とかにしないと...

はて？
うちのdebianくんは、KDE3.2をスタートした時点で、トータル100MBも使ってないけど。
しかも、SendmailやらApacheやらいろんなサーバが起動した状態で。

>>577
tvtwmは使わなかったがtwmは使ってみたよ
結果は全くだめ
問題はX自体のメモリ消費量なんだよ

>　AfterStepじゃだめだ、tvtwm(twmよりも何故か軽い) とかにしないと...
こういう事言ってる事自体が重い証明だろ

フォント読み込みすぎだったんじゃね。
あとtwmよりfvwmのほうが軽かったような。

>>578
>　うちのdebianくんは、KDE3.2をスタートした時点で、トータル100MBも使ってないけど。
それは異常だよ
漏れは256MBのVine機を持ってるが、Xを使ってしばらくたつと必ずスワップする
俺もLinuxは好きだが、神話はうんざりだ

もうコンソールでいいよｗ

でもFSが壊れるのは神話じゃなくて事実だよね。

VFSが安定しない限り、この状況は続く...

昔 166MHz 32MB で X と windowmaker と emacs と kterm 同時に使ってたけど
普通に使えてたよ。XFree 3.x 時代ね。
さすがにネスケとか立ちあげる時は emacs 落とす必要があったけど。
ただ、その後 update していくなかで X はどんどん重くなっていったので、
最新の X 入れたりしたらさすがに32MBじゃ足りないんじゃないかな。

はて？
うちのUbuntuくんは、Gnome2.16.1をスタートした時点で、600MBも使ってないけど。

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。

>>581
スリープ中のバックグラウンドプロセスじゃないの？

サーバでGUI常時動かす時点でどうかしてる。
ところがwindowsはGUIにOSがくっついていてGUIを止めれない。

スレ本来のFSに注目すると、
windowsのFSが逝きにくいのは事実。
だけれども、書き込み時のバッファフラッシュが強烈に重い。

linuxはVFSの段階でアクセスを最適化しようとするので重くなりにくいが、
その反面電源落ちクラッシュしやすい。

昔のは本当に軽かったんだよ
最近のは Window Manager に何を使っても重い
長年 fvwm だったが beryl にしてエフェクト使いまくっても
その差が体感できなかった

>>584
実用に耐えなかったというのはあくまで自分の主観で、遅くても動いていたことは間違いない
これを使えると思うかどうかは、各自の主観によると思う
しかし、後でWindows95とデュアルブートにした際にWindows95の軽さに驚いた
実機で16MBでも快適動作するのを確認している

ここって何のスレ?

Windows9x系はさすがに話にならんだろ。
しかしNT系になって実装もそうだけど、設計でもUNIXは抜いたと思う。
MSは実装だけでなくアーキテクチャ設計能力も高い。

特にサードパーティによる新デバイス対応やOS拡張ができるようにする
モジュール構造は実世界で揉まれてるだけあって先を行ってるし、
どのOSでも一番問題を起こすドライバ系の安定度を高めるための
検証フレームワーク整備や教育といった面でも抜かりない。FS面でもNTFSは
安定してること以上にマルチストリームとかトランザクション対応とか
新機軸を着実に導入してるし、ユーザランド側でもPowerShellとかWSHと
いった洗練された仕組みがここ１０年で着実に入ってる。

元ネタが○×でコピっただけとか厨が煩いことがあるけど、設計・実装は
NT登場以来驚異的に高くなってるし、そもそも他の会社が対抗できてない。
上から下まで、技術・非技術面までひっくるめて整備してくるMSのこの底力が
一番すごい。

正面からNTFSに対抗できる存在としてReiser4に超期待してたんだけど・・・
まあReiser4が駄目でもZFSとかFUSEとかGFSとか面白いものはたくさん
あるけど、MSは侮れんよ。

Reiser4、漏れも期待していたけど、あの様子では主流にはなれないだろうな。
いろいろな意味で...

結局、Linuxカーネル開発者な連中は、Reiser4を闇に葬るんじゃないだろうか?

> ここって何のスレ?

top の出力眺める誰でも出来る仕事の人が、日頃妄想していることを書く場所。

>>593
確かにいい口実にはなったよな。

カーネル開発者たちはReiser4が独自IOルーチンを実装していることを非難してるが、
ReiserFS側が一方的に悪いとも思えないな

>Reiser4が独自IOルーチンを実装
XFSは良くてReiser4がダメな理由ってなんだろ？

>>597
開発者の性格

Hans Reiserが嫌われてるからだろ

ユダヤの陰謀

lustre1.6beta7を入れてみたのだが、OSTをmkfs.lustreしたあとmountするところで
カーネルパニックしてしまう。
beta7ちゃんと使えてる人いたら教えて下さい。

しかし、Reiser4の開発者の性格がいくら悪くても、
漏れ的には、今まで一番トラブルの無かったファイルシステムが
ReiserFSなんだよな。
というぐらい今まで、LINUXのFSには酷い目にあっている。

>>596
Linuxの悪口として、I/Oが腐っているというのはよく言われることだからね。
独自実装したくなるぐらいに腐っているというのを、Linux系の有名開発者自らが
実践しちゃったんだから、kernel開発者としては捨て置けなかったんだろうけど。

Hansを非難するよか、まともなI/Oを実装することに力を注いでほしかったね。

具体的にI/Oのどの機能がよくないんだ？

reiser たんは、あれだよね
他のカーネル開発者への礼節が欠いてるんだよな
それで嫌われてる、確か

http://bulk.fefe.de/
の
filesystem: Unix filesystem scalability benchmarks (Linux Kongress 2006)
は、単純なベンチとはいえFSでこんなに違うんだなーってのが分かるな。
reiser4が速すぎで、嫉妬心から嫌われる理由になるのも分かる(違

信頼性を定量的に測定できればいいのにね。

詳しいことはよくわからないんだが、
ﾗｲｻﾞｰのｺｰﾄﾞにはassertﾏｸﾛがたくさん入ってたので、あるｶｰﾈﾙ開発者が「読みにくいから削除してくれ」と注文をつけたらしい。
ﾗｲｻﾞｰが「そんなこという奴は素人だ」と言い返したので、こじれたのだとか。
逸話が本当なら、ｶｰﾈﾙ開発者が素人なのは間違いないが、ﾗｲｻﾞｰももっといいかたがあっただろうにな。

Reiser4はﾌｧｲﾙｼｽﾃﾑのｻｲｽﾞ変更に対応してないんだよな。
先日、変更が必要になってそのことに気付いた。
ﾃﾞｰﾀの引っ越しがめんどくさかったのでいまはﾊﾞｰｼﾞｮﾝ3を使ってる。

ところでevms使いこなしてるひといる？
なかなか思うようにならなくて苦労してるのだが、、

UNIXのファイルシステムは、みんなトロイのばっかだからな
ディスクアクセスがいま一番ボトルネックで
データベースとかのベンチだと、明らかな差が出てくる
データベースはできるだけオンメモリで動作させるのが鉄則で
できるだけディスクアクセス少なくするんだけど
それでも、ディスクアクセスは避けられない
LAMPがはやるのもわかる気がする

最後の文との関連が意味不明

Gentooの創設者もいってたな
あんなとろいファイルシステム使ってたら、日がくれちゃうよってw
Gentooはコンパイルして、ディスクアクセス頻繁に行うから

GentooはReiserFS推奨なんだっけ?

ttp://www-06.ibm.com/jp/developerworks/linux/011109/j_l-fs2.html
古いけど、ext2で2分かかっていた処理がReiserFSでは15秒で終わるって言ってる。

パフォーマンスと引き換えにファイルロストというすばらしい特徴を備えているけどなorz

2.6.10くらいからしか使ってないが、ファイルロストなんてないよ。
FUDイクナイ

>>615
その昔にはあったんだよ。俺も引っかかったが。
ファイルシステム全体が破損して復旧不可能になるという素晴らしいバグが。

Hans Reiserの件は抜きにしてもその時の記憶があって精神的に
reiserfsを使いたくないというユーザが数多くいたりする。

IBMはいつのまにこんな文章のせてたんだ
俺もReiser使ってみよ

kernel 2.2時代の話を蒸し返されてもねぇ

2.4だろ

>>616
どこで聞き齧ってきたのか知らんが、過去に騒がれたのはバグじゃなくて互換性。
バージョン間の互換性が低くて、古いカーネルでマウントして壊す奴が大漁発生。

>>620
それは十二分に致命的なバグだろうに。
あとscpするとファイルシステムごとクラッシュする問題もあった。

>>609
データベースでファイルシステムがボトルネックになる時は
raw モードを使うよね。製品ごとに呼び名は違うみたいだけど。

ぼくも raw モードでセックルしていまつ。

>>607
アサーションはきちんと入れた方がいいよな。
プログラマーの意図を的確に表したアサーションはコメントに勝ることも多いし。
本当に必要なアサーションをさして、あるいは特定のアサーションを指さずに
全体的にアサーションが多めというだけでアサーション減らせって
指摘したならそいつの方が間違いだと思う。
実際にコードも読まずにこれ以上なんとも言えないけど。

> 実際にコードも読まずにこれ以上なんとも言えないけど。

あることないこと書いて炎上するほうが楽しくね？

ようするに全てはユダヤの陰謀ってことで

Reiserの逮捕事件って、実はkernel開発者の陰謀だったりして。

NovellがMicrosoftへの忠誠の証として人身御供にされた...とか。
もしかしてSCOのダールたんが暗躍してたり。

>>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して使用する以外なら。。

>>470
ヨーロッパの寺院とかに行ってみろ
墓標の上をみんな歩いてて、石の表面に彫られた文字も
磨り減って読めなくなってるから

ベトナムで鳴らした俺達ファイルシステム部隊は、濡れ衣を着せられ当局に逮捕されたが、
刑務所を脱出し、地下にもぐった。
しかし、地下でくすぶっているような俺達じゃあない。
筋さえ通ればフォーマット次第でなんでもやってのける命知らず、不可能を可能にし巨大なファイルを
貯蔵する、俺達、ファイルシステム野郎Ａチーム！

俺は、リーダーntfs。通称MS謹製。
大容量と耐障害性の名人。
俺のような高信頼性FSでなければ百戦錬磨のつわものどものリーダーは務まらん。

俺はext3。通称Linuxの落とし子。
自慢のジャーナリングに、UPSはみんなイチコロさ。
ハッタリかまして、大容量ファイルから大容量ボリュームまで、何でもそろえてみせるぜ。

私は、HFSX、通称マカー。
チームの紅一点。
相互互換は、美貌とAppleTalkで、お手のもの！

よおお待ちどう。俺様こそRaiserFS。通称クレイジーFS。
アクセス速度は天下一品！
飛ぶ？壊れる？だから何。

FAT32。通称DOSあがり。
ロングファイルネームの天才だ。リソースの少ないPDAでもブン殴ってみせらぁ。
でもOver2GBだけはかんべんな。

俺達は、道理の通らぬ世の中にあえて挑戦する。
頼りになる神出鬼没の、ファイルシステム野郎 Ａチーム！
助けを借りたいときは、いつでも言ってくれ。

元ネタ古いなぁ・・・

別にそれぞれキラリと光るキャラ設定があるわけじゃないし

だよね。
ジェネレータみつけて勢いにまかせて作ってやり場に困って投下しました。
ごめん。

まあいいんでないか。

あのさ、あのさ、今さらながら reiser さんの良からぬ話を知ったんだけどさ、
今、会社で管理してる ReiserFS なサーバーは、やっぱり次に再インストールでもする際に
ファイルシステムを変えたほうがいいと思う?

まったく思わない。

ReiserFS 3.xは既に開発が終わり、カーネルにマージされてるから当面は問題はないでしょ
Reiser4はカーネルにマージされていないのでこれも問題ない

漏れは当面は様子を見る

＞ReiserFS 3.xは既に開発が終わり、
メンテされなくなったら、追い出されるよ。

いずれな

ext2はどうなんだ?

追い出されるのが、例えば数年後なら俺的には何の問題もない
開発がストップしていれば性能面の魅力も消えているだろうから

しかし、状況は流動的

ext2は　fsckが死ぬ程遅いからなぁ。

Linux終ったな

ext2でいい用途なら、ext3でいいのでは？ >> 643

>>645
> ext2でいい用途なら、ext3でいいのでは？ >> 643

一長一短
ext3はext2より遅い
実際比べてみればわかるよ

xfs_fsrがあるから、xfsをえらぶ

>>646
外部ジャーナルでdata=journal

速さが欲しけりゃtmpfs、ramfsでも使ってろって

>>648-649
>645は
> ext2でいい用途なら
と発言してるんだが

正直なところ ext2 や ext3 よりは 速度面から考えたら
ReiserFSやらXFSやらの最新のFSを使いたいが、
結局、ext2 or 3 よりも安定性が低いんだよね。

>>651
そんなことはない

現時点に限ればReiserFSやXFSは安定性で勝っても劣ることはない

Reiserが安定しなかったのは過去のこと、っていうのはわかる。
でも今ext2や3よりも安定しているのを求めている以上、
どういう理屈で、どの程度安定しているのかという情報は欲しい。
でないと水掛け論になりかねん。

xfsってもう十分実用になってるの？
数年前にreiserfs3で入れてからしばらく情報集めてなかったんだけど、
次に入れる時にext3に戻るかxfsにするかで迷ってる。

>>654
> どういう理屈で、どの程度安定しているのかという情報は欲しい。
そんな事ができる人がどこにいますか？

私が言えるのは、自分の経験とこのスレの過去ログぐらい
ext2や3で被害にあう方が圧倒的に多い

>>655
十分実用になってます

xfs って、うちの会社のサーバーじゃオーバースペックな気がしてなぁ。
だからといって ext3 じゃトロいしなぁ。
というわけで、ReiserFS を使ってるんだよなぁ。
何だかなぁ……。

>xfs って、うちの会社のサーバーじゃオーバースペックな気がしてなぁ。
これってどういう意味でしょう？
そのサーバーで使うには、負荷が高いという意味？(機械にとって)
その用途で使うには、機能が過剰という意味？(目的に対して)
それとも、管理が面倒すぎるっていう意味？(人にとって)

>>656
でもReiserで過去に失敗した人がReiserよりext、って言ってるわけでしょ。
それは>>620の問題があって、それに引っかかった人だと思うけど。
過去の経験を補強する情報がなければ結局水掛け論になるよ。
たとえばSunなんかはZFSの信頼性は99.9999……％云々っていってるけど、
ああいう形で信頼性を示せれば信頼性に関する議論も進むし、
そういう情報が欲しいといってるわけで。
（その信頼性を実現する仕組みに関する簡単な解説でもつけてくれればなおいい）

Sunの99.9999...なんてマーケットトークに決まってんじゃん。
実装バグで起きる問題の確率が事前予測できるわけない。
まあ、商用製品で正式採用する以上、テストパターンを網羅して
走らせるだろうから、最終的には上の信頼性だろうけど。

安全性設計の部分だけに評価して各FSを比較できないもんかなぁ。
あとは実装容易性の評価とか。

信頼性って評価難しいよなあ。
参考までに俺は各種サーバ(主にファイルサーバー)約10台
計約50TBを xfs で使ってる。信頼性に関していえば ext3 と比べてどっ
ちが良いかはよく分からない。性能など信頼性以外の面では xfs
が優れてだと思う。freeze もできるし。

話題の ZFS についても壊れるというのはまだ経験ないけど、ファイル
システム関連の操作が引き金になってOSが固まるとい現象はよくある。
今日も zfs destroy の最中に固まった。

HDDの信頼性測定とかは1000台近くを何日か稼動させて
故障台数とポワソン分布で計算するんだってさ。よくわからんけど。
fsみたいな故障しにくいものを測定するにもそんなやり方でやるのかね？

>>662
それはMTBFあたりを出すときのやりかただろ？

ポワソン分布でなにかまずいのか?

カイ2乗検定とかじゃないの？

最近、GoogleがHDDの故障率のレポだしてたけど
あれ各種ファイルシステムでレポ欲しいよなあ

ext2 の上に GFS (google file system)っていうのは昔の話？

>>659
要求しているのは、信頼性の定量評価でしょう
それなら、検証するための条件を実際に出してほしい
それは無理でしょう

>>659
>　でもReiserで過去に失敗した人がReiserよりext、って言ってるわけでしょ。
>　それは>>620の問題があって、それに引っかかった人だと思うけど。

例えばこのReiserFSのバージョン間の互換性の問題。
これを信頼性の比較テストで見つける事は非常に難しい。

へーそんなに互換性低いんだ。
Linux2.4の頃からずっと、reiserは3.6で止っていて大丈夫だと思ってた。

3.5の時代だろ。

>>670
2.2カーネル+ReiserFSパッチと2.4カーネルにマージされたReiserFSとの互換性
2.4カーネルでマウントできなかった

なんだ、そんな昔の話かよ。
しかも、カーネルに統合されていない時代の話しだし。

>>673
2.4カーネルは安定性に大きな問題があって、長期間に渡って2.2カーネルと併用されてた

それは違うだろ。
はるか昔から、安定版、現行版、開発版という体系だったんだから。

ディストリでの2.4の採用が大きく遅れたんだよ

676のいうディストリを挙げてくれないか？

カーネル2.4のリリースが2001年1月10日
SUSEはすぐに取り入れ2001年2月
Turbo Linuxは少し遅れ、2001年5月
Red Hatは1度2.4のリリースを見送り2001年9月
保守的な
Vine2002年4月
Debian2002年7月

2.4ではVMがなかなか安定しなかった希ガス。
Linusがファビョって途中でVM入れ替えてた希ガス。

>>678
で、2.6の場合は？

>>680
自分で調べてくれないか？
2.4は肝心のRed Hatがリリースを見送ったのが痛かったんだよ

ID: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が取り立てて遅れたとはいえない。
ディストリ＝レッドハットしか頭にない誰かさんには
けしからんかもしれんがね。

>　2.6.0リリース: 2003/12
>　SUSE: 2004/3(2.6.4)
>　Turbo: 2003/10(2.6.0test5)
>　FC:2004/5(2.6.5)

保守的なディストリ以外はすぐに入ってるじゃないか

2.6 の方が断然採用が遅れてるのに目を向けられない ID:assudzzV

>>661
誰かファイルシステムの信頼性テストアプリ書いたら面白そうだね。
以下の処理をランダム（どのファイル／ディレクトリ、どの処理、何回）で実行。
作成するファイル名やディレクトリ名もランダム。

ファイル読込、ファイル書込、
ファイル作成、ファイル削除、ファイル移動、
ディレクトリ作成、ディレクトリ削除、ディレクトリ移動。

他にもメモリをぎりぎりまで使ってる状態でのテストや、
LoadAverageが10超えてる状態でのテストや、
上のテストを複数のボリュームに大して同時実行とかもやってみるといいかも。

>>686
書き込み中の電源断は必須項目だよ

>>686
その仕様でｵﾏｲが書いてｸﾚ

>>686
信頼性を「定量」するんだからな
ちゃんと何が起これば何点という重みもつけてくれよ

>>668
６５４＝６５９＝俺。
６５４では定量評価と書いてないので納得してくれ。
定量評価が無理なのには同意する。

各ファイルシステムでランダム書き込みテスト中にシャットダウン。
これを１０万回位して有意な差があるかどうかで定量評価できない？

あとは実験ではなく書き込みアルゴリズム部分を抜き出して
相互比較するくらいか＞安全性の比較

10万回って… 何年かける気だよ

>>691
教祖にでも頼んだら？

>>687,691
電源断したら、10回に1回ぐらいでHDDが物理的に死ぬんじゃないかな。
昔UPS買う金もなかった頃、停電で5台のサーバ中1個ぐらいHDD壊れてたし。

>>647
それは言える

Google File Systemってどんなの？

Gmailをバックエンドとしてマウントする、たんなるネタ。

それgmailfs

まあ普通にやるならポア損だろう

>>696
つ[http://216.239.37.132/papers/gfs-sosp2003.pdf]
ファイルシステムとしての機能は実装されているが、このスレで話題にするような
ものとはレイヤが違う希ガス

「POSIX互換なファイルシステム総合スレ」にすればいいのかな。

>>694
>　電源断したら、10回に1回ぐらいでHDDが物理的に死ぬんじゃないかな。

何でそんなに死ぬんだ？

電源断が理由で起動できなくなった時に俺も物理的に壊れたと思ってた事があったｗ

むかーしのHDDは電源ぷっつんで、死んでたけどね。

それは20MBのHDDの時代だろｗｗｗ
流石に、100MB超えたらヘッドの待避はしてるから。

namesysでそんなテストやってなかった？
速度比較だけど内容はそんな感じだったよ。
しかし、一回でもエラーがあるようならﾌｧｲﾙｼｽﾃﾑとしては致命的だよね。
書き込み途中のﾃﾞｰﾀが電源断で失われるのは物理的に回避不可だからUPSなんかに頼るべきだけど、
それ以外のエラーはあってはいけないよね。

>>702,704,705
40〜80GBぐらいのHDDだったはず。
ひょっとしてかなり運が悪かったのかな？

>>706
>　書き込み途中のﾃﾞｰﾀが電源断で失われるのは物理的に回避不可だからUPSなんかに頼るべきだけど、
>　それ以外のエラーはあってはいけないよね。

ファイルシステムが逝く大きな原因の、書き込み中の電源断をテストから外したとする
そのテストで良い結果が出たら、信頼性のあるファイルシステムだと誰が思うんだ？

いぁ、家庭で使ってるようなあれで、HDDに書き込みしてないのがほぼ確認できた
時点で電源落としてればほとんど問題はないだろうし、サーバーで使ってて
いつ何をやってるのかよく分からない状態で電源が落ちればHDDやられるだろうし、
ケースバイケースなんじゃね?

/dev/sdX を read,writeするプログラムを書いて
電源斷すれば、ハードのせいかファイルシステムのせいか
はっきりするだろ？

書き込み中の電源断テストをしないで、いったい何をテストするのやら

> 流石に、100MB超えたらヘッドの待避はしてるから。

根拠をきぼんぬ。

電源断は本当に壊れたら困るから、IDE のケーブルを抜くってのは?

ジャーナリングファイルシステム自体が
書き込み中の電源断に備えてジャーナルをせっせと書いているわけだろう
これをテストしないでファイルシステムの信頼性テストができるの？

そうそう

>>705
うん。ストップボタンがついてるやつな。

>>714
なるほど。
ケーブル抜くとか物理的な方法だと何回もテストが大変だから、
強制アンマウントとかできないかな？

USBでアナログスイッチ制御してバスをいきなり切り離したりすれば
いいんじゃない？復帰させる時はバスつなぎ直してからモジュールを
リロード。

それだと既にHDDのキャッシュに入ってる分が安全に書き込まれてしまうかもしれない。

IDEのケーブル抜くのは、HDDのディスク面への傷はつかないかも知れないが、
インターフェイス部分を電気的に壊すかもしれないぞ。

それだったら、リセットボタンを押して強制リセットの方がハードウェア的に安全だと思う。
少なくとも強制リセットでXFSはFSが壊れたことがある。

スループットなら iozone があるけど、
メタデータ部分に関するストレステストのようなものは
広く使われているものってあるかな？

まずは、ファイルシステムが壊れた、の定義からだな。
そうして話はループする。

つーか書き込み中でもHDDのヘッドは浮いてますぜ。

IDEじゃダメなんじゃないの？
IDEはハード的に厳密な書込み保障してないんだろ？

そのためのUPSだろ？
Linux鯖でシャットダウン用UPSなしはありえないだろ。常識的に考えて。

ループしすぎ

LinuxはVFSが腐ってるから。

VFSって何？

掃除のおばちゃんがUPSの後ろからサーバーのコンセントを引っこ抜いちゃった時を想定してテストするんだよ。

？？？

１他のﾌｧｲﾙ書込み処理中のﾄﾗﾌﾞﾙで既存ﾌｧｲﾙが壊れるのはﾌｧｲﾙｼｽﾃﾑの問題だが、
２書き込んでいる最中のﾃﾞｰﾀを保障する方法はないだろう？
ところで、１の状況になるような不出来ﾌｧｲﾙｼｽﾃﾑでは致命的だよね？
現実的におこる可能性のあるｴﾗｰと言えば、ﾋﾞｯﾄ抜けなどによるﾃﾞｰﾀｴﾗｰなんかだと思うのだが
ｴﾗｰ訂正機構などで回避するのがFSの役目じゃなかろうか。
ｴﾗｰ訂正できずひたすら読みなおすようではちょっとね。

?

>>724
>　IDEじゃダメなんじゃないの？
>　IDEはハード的に厳密な書込み保障してないんだろ？

>>553

$ nl linux/include/linux/ata.h |grep FLUSH
115 ATA_CMD_FLUSH = 0xE7,
116 ATA_CMD_FLUSH_EXT = 0xEA,

>>725
>　そのためのUPSだろ？
>　Linux鯖でシャットダウン用UPSなしはありえないだろ。常識的に考えて。

UPSおおいに結構
しかし、ジャーナルの話になる度にUPSの話を持ち出すのはやめてくれ

１．まずベースになるファイルシステムの信頼性を上げる
２．その上で更に安全性を確保するためUPSを使う
これが基本じゃないのか？

ID:9eNEo15tみたいに根本的にわかってないヤシは放置しとけばいいのに

FS以前にVFSが腐ってるんだからUPS付けるしかないだろｗ
なんでも安いものには訳があるんだぜ

VFSってなに？

UPSをつけても治らない病気

xfsは独自のインタフェース等をもっていたけど、
VFSをベースにするように書き直す動きがでてきたようです。
ttp://marc.theaimsgroup.com/?l=linux-ext4&m=117164238303188&w=2

>>738
聞く前にググろうぜー
ttp://ja.wikipedia.org/wiki/Virtual_File_System
ttp://www.atmarkit.co.jp/flinux/rensai/fs01/fs01a.html

しかしLinuxってVFS以外はかなり良いのに、VFSが大きく足を引っ張ってるよね。
高負荷時にIOwaitに取られて、パフォーマンスがた落ちするし(とくにext3)、
私の環境だとよくファイルシステムが壊れるし。

「腐っている」と批判される VFS を改善する
という動きはないんですか？

といっても Linux は MPI 使ったシミュレーションと
LaTeX での物書きくらいにしか使っていないので
具体的にファイルIOが高負荷になったら
生じるという問題には遭遇したことがないのですが。

>>741
39s 理解が深まりました。
ところで>>742も書いてるけどVFSのどの辺が悪いの？
ｻﾝはﾌｧｲﾙｼｽﾃﾑまわりが良いとよくいわれるけど、実感したことがないんだよね。
直接比較しにくいから「体感速度」でしかないけれど。

気にならなければそのままでいいんじゃない？

>>742
Linus「頑張りな」

UPS、UPSってループしすぎ
UPS使ったらFSの問題は修正する必要がなくなるのか？

>>742
改善しようとして入る大きいバグよりは、
現状の踏む確率の低いバグの放置を選んでいる、と前スレで見た気がする。

>>746
んなわけない。
kernel(fs)の話なのにUPSを持ち出すほうがアホ。

なんでUPS持ち出されると火病るんだよｗｗｗ
現状のKernelがしょぼいからHWでその穴埋めをしてるだけの話だろｗ

kernelがしょぼいならNexenta使えばいいじゃない

最近はFS<->DeviceDriverは、キャッシュフラッシュ機構を伴ったfs/deviceだとちゃんとフラッシュするようにしてるとオモタ。
user<->vfs<->fsはここが最近かつ長い論議になっているな
http://groups.google.com/group/linux.kernel/browse_frm/thread/e6e6c02f1c62407f

O_DIRECTっつーキャッシュを使わないフラグの話なんだが、O_SYNCとかもからんでくる。
rawデバイスへのIOなら意味はあるかもしれないけど、fsレベルだとkernelがする仕事いろいろあるのでどうかねぇって感じかね。

>>741
kernelとioスケジューラとmount option何?

低脳の俺じゃ話についていけん、離脱する。

>>748
穴埋めきれてないから

>>752
BSDに転向しま〜す

>>750
raw deviceにつづいてO_DIRECTも無くそうって話が確かその後にあったとおもう。
どちらも移植性以外にメリットがなく、O_DIRECTを使わないプロセスとの
キャッシュの整合性をとるのが難しくて、デバイス全体(/dev/sda)のopen時
くらいしか意味がなく、それだったらSG_IOつかえばいいじゃん、って話。

>>750
kernel 2.4.21-37.ELsmp
mount option は defaults,noatime
IOスケジューラはkernel 2.4だから選択不可

kernel 2.6ではまだ高負荷サーバの運用経験なし。
たぶん2.6にすれば、だいぶIOwait解消するとは思うけど。

(´-`).｡ｏO(2.4.20のリリースは2002/11/29....)

(´-`).｡ｏO(2.4.21のリリースは2003/06/13....)

>>755
　 i　　　　 ,､　n　て'' ノノ　　　　ヾ　　 !
　 i　　　　ﾉﾉノ ﾉ ノ　''´　　　　　　!　 /
　 　　　j　　 ' ´　　　 ﾉ (　　　　ヽ　|
　>-,,　 /　　,,=━━・!'　,ﾉ━＝=　! ﾉ　　　　だいぶIOwait解消するっていうレベルじゃねぇぞ！
　!・　 ヽ |　　’ﾆﾝniii､　:::::i/ｨ7iii=　 i )
　＼（てi iヽ　　 ^'　~　　　　　-'　　/｝　　　　http://osdn.jp/event/kernel2005/pdf/comware.pdf
　　｀i_ 　 ､ ＼　　　 　　 　i_　　　　l_j　　　
　　　｀┐　i　　　　／(,,,　,n 〉　　 /＼＼
　￣￣へ　　　　! '　　　T'' 　　　l |　　＼
　　 ｜　　!　i　　　　ン=ｪｪi) i　ｿ　)　　　　　　　　
　　　|　 i´＼!　,,　-ｪ｀､＿ﾝ ﾉノ　〈
　　　|　 |　　＼＼,,　｀―''´／/　　|　　　　

syncもすっ飛ばしてしまえば、IOwaitなんて関係ないわなｗ

>>756-758
2.6にすればパフォーマンスが上がるというのは分かってるんだけど、
メンテで１時間止めるのも難しい状態だから、いつになったら2.6に差し替えられるのか…。

2.6.x になってもVFSの酷さは相変わらずだよな。

仮想マシン使ってテストすれば
機械的問題なのかfsの問題なのかわかるんじゃないの。

仮想マシンがバグったらどうすんのさ

>>762
それはなかなか良い案だ。
メモリ割当量とかも好きに設定できるし。

あとは誰かプログラム書いてくれる神さえいれば。

>>712
電源が切れたら、ゴムひもの張力でヘッドが勝手に戻る
ttp://www.youtube.com/watch?v=9eMWG3fwiEU

それ面白いな。ほかにもいろんなHDDの使い道が出てて面白い。
http://www.youtube.com/watch?v=yISqCAnROh8
http://www.youtube.com/watch?v=8GT2WrsCDmI

>>759
>　syncもすっ飛ばしてしまえば、IOwaitなんて関係ないわなｗ

そんなことはない
ディスクのキャッシュには書き込む必要があるから、IOwaitは普通に発生するよ
syncすっとばして問題が解決するなら、なぜ2.4カーネルでこの問題が起きてるんだ？

>>750
よく考えたら、kernel 2.6で高負荷サーバ稼働してるの忘れてた。
kernel 2.6.9-22.ELsmp
mount option: defaults,noatime
IOスケジューラ: cfq

postfixでメルマガ配信してると、以下ぐらいの負荷になってる。
kernel 2.6でもiowait発生してる。

eth0 traffic: 2Mbps
LoadAverage: 8
CPU usage: system 20%, user 20%, iowait 100%, idle 60%
Processes数: 230
Fork rate: 30〜50
context switches: 4k
inode table size: 70k
open inodes: 65k

それいつの時代のカーネルだよｗ

>768
そのマシンのスピンドルは幾つですか?

2.6.9-22.ELsmpでググると2番目に
http://bugs.centos.org/view.php?id=1064
が速攻出てくるけど。
なんかそのカーネルかディストリがおかしいんじゃねーの?

>>770
メインにSATA 240GB(RAID 1)で、バックアップ用にSATA 160GB。

つか、iowait100% にしてて、ど〜しよ〜なんて言ってる時点で向いてないね。
solarisいれてCTCにでもサポートしてもらったら？

もっと突っこんだのがあった。特定のverだけおかしいぽい。
http://www.vbulletin.com/forum/showthread.php?t=171071

>>771,774
ほー、RedHatのリリースノートには書かれてなかったから、気づかなかったよ。
今度、メンテ承諾もらって、updateしてみるかな。ありー。

http://www.ntfs-3g.org/
NTFS-3G Read/Write Driver が 1.0にバージョンアップしてる。

http://www.ntfs-3g.org/quality.html
書込みも問題なさそうだ。

今日から /home に ext4dev -extents を使い始めました。
お世話になります。よろしくお願いします。

FreeBSDで使っていたUFS2のHDDがあるのだけど、これを Linuxで使う場合、
UFS2のままmountとして使える?
また、もしできた場合、安定性や速度面の問題ってある?

とりあえず、Gentooで使うつもりなんだけど、kernel はできるだけ新しいのを
使う予定。

>>778
http://vivian.mysite.ddo.jp/modules/newbb/viewtopic.php?topic_id=14&forum=5
速度や安定性は人柱になってくれ
ソース少ないから

ソフトアップデートは無理だろうが、非同期書き込みのはずなのでext2ぐらいの速度？
漏れにはわからね

一つ気が付いたんだが、安定性は問題ありじゃねえ？
非同期書き込み（未確認）、ソフトアップデート無（未確認）、ジャーナル無で電源断の場合、
高確率でFSの不整合が起きると思う
その場合fsckができないんじゃない？

>>780
Linuxのext2のfsckはそういう状態からでもかなりの確率で無事に
復活するように作ってあるけど、ufsのfsckは割と根性無しなんですよねえ。

>>747
| 改善しようとして入る大きいバグよりは、
| 現状の踏む確率の低いバグの放置を選んでいる、と前スレで見た気がする。

2.7のような「開発版」kernelが出てこない限り、大きな変更は出来ないだろ。

>>775
| 今度、メンテ承諾もらって、updateしてみるかな。ありー。
テスト環境で試すんだよな、まずは。

やつの性格からして無理だろ。

>>782
2.6は安定版と開発版を兼ねてるけどな。
というか開発版を作ると安定まで時間かかるから
一緒にしてる時点で問題な気がする。

>>779
>>780
>>781
レスありがとう

FreeBSDとLinuxでデュアルブートをしたいと考えているんだけど、
ufsが安定しないならちょっと面倒かな。

スピードもメディア使用効率もREISERが一番だと思うんだが
ほかのFS使うメリットってなに？

Reiser が怖いという人もいるんじゃないか？

>>787
今後の開発継続に対する信頼性とか。
さすがにRaiserみたいに、メインの開発者が被訴訟中とか不安よ。

トラックナンバーが高いというのが問題。

低いだ。orz

>>789
現行の物を使う分にはディストリビューターがサポートするんだし、問題ないべ。

>>792
Reiser3を使い続けるのならそだね。いまさら大きなバグとか出てこないだろうし。
問題はReiser4。fs自体の開発もそうだし、kernelにマージされていないから、
それに追随していくだけでも面倒だし。

>>792,793
でも、この前SUSEのカーネルメンテナーがもうやめって言ってたから、
ほとんど誰もメンテできないに等しいのでは？
reiser3の大きなバグは公称16TBサポートなのに、実際には8TBしか
使えないことかな。

それは実用上差し支えあるのかな？
reiser3は実質ﾊﾞｸﾞﾌﾘｰに近い状態だからﾒﾝﾃが重要とは思えないのだけど。
reiser4は未完成品だから ｶｰﾈﾙにﾏｰｼﾞされないのはある程度しかたない。
手軽に使いたければmmｶｰﾈﾙという道はあるんだし。
というわけでreiser3を使わないとすれば、理由は根拠希薄な不安感というしかないのじゃなかろうか。

ファイルシステムは壊れるような使い方をするソフトやユーザーが悪い

ソフトやユーザーが壊れるような使い方をして壊れてしまうファイルシステムが悪い

全部俺が悪い

>>797
ファイルシステムのせいで次々に壊れていくユーザーたちの様子を想像した

8TBも16TBも、もう見えている制限やね

796 名前：login:Penguin[sage] 投稿日：2007/02/26(月) 13:12:31 ID:wkQWJiQy
ファイルシステムは壊れるような使い方をするソフトやユーザーが悪い

797 名前：login:Penguin[sage] 投稿日：2007/02/26(月) 13:53:32 ID:V6eujtdB
ソフトやユーザーが壊れるような使い方をして壊れてしまうファイルシステムが悪い

当然あるべき姿は後者だわな

つまりﾗｲｻﾞｰでｫｹということだね？

俺もReiserがいいと思う

現状reiserfs一択

reiserfs がクソということが決定したようですね

>>795
実用上という点では、実際に問題にぶつかったかどうかで、
ファイルサイズの制限はうちが喰らった問題だし、
セキュリティー上の問題は皆が困るしね。

メンテナ不在というのは、モートンたん以外にパッチの
拾い手がない今の状態を言ってるの。

>>806
カーネルにマージされている以上、重要なバグはメンテされるよ
サイズの問題はバグでもあるが、それ以上に仕様自体が限界の部分が大きい
スケールが必要な人は自分に必要なFSを選ぶべき

>>798
神!

FUSE/ZFSっていまんとこどうなの？
使えそうな感じ？

>>807
重要なバグが出たら reiserfs は切り離されるんだな。はやく切り離されないかなぁ。

ZFSがFUSEで使えてもちっともうれしくないだろ。
NTFSのように安全に読み書きしさえできればいいってもんじゃないし。

>>798
Hansたん？

>>810
そう簡単なもんじゃないよ
安定版カーネルに、
運用上の障害になるような変更を加えるのはかなりの事態だからな

2.6 系のバージョンアップの課程であっさりと pc98 コードは削られてけどな。
アーキテクチャ丸ごと消滅だぜ。
reiserfs は回復不能なバグが発見された後さっさと消えてほしい。ソースコードの容量の無駄。

それは感情的な問題だね

>>814
それはやる気の問題で削られただけだろ

reiserfsのメンテナにやる気があるのか?

ﾗｲｻﾞｰは現行ﾊｰﾄﾞｳｪｱで現役だがPC98はどうかな？
ということでしょ。

結局、妻殺人犯ということでいいの？

ユダヤの陰謀

Linuxを不安定なままにしておきたいと一番強く思ってるのはIBMなんじゃないのか

なぜ？
Linuxをここまで大きくしたのはIBMだろう

コントロールの元におきたいだろうな

>>822
でもねーんじゃねーの？
どっちかというとIBMの法則が炸裂してOS/2化してる気がするが

>>824
IBM抜きで今ほどの勢力になれたのかな？
ただし、IBMはLinuxをつまらなくしたとは思う

現状のLinuxについてIBMの貢献はそれほど大きくないし
これからもそうだと思う。
金の成る木だから寄ってきてるに過ぎない。Novellにしてもそう。
でも使えるリソースは使うに限る。

IBMはSolarisを駆逐したかったんだろ。
Solarisと心中できるなら、AIXくらい死んでもいいと。

>>826
Linuxの開発に対してのIBMの貢献はそんなに大きくないけど
普及に対しての貢献は、とてつもなく大きいよ。
その結果として、開発者のが集まったという面もあるし。

何の話し？

>>817
NovellのメンテナがブータレてSUSEのデフォルトから外されたけど、
メンテは継続するするという話だったような。

>>830
そんなの出来る人材がほいほい居るとも思えんが
・・・・いまのNovelにね。

なんでそう自虐的かなあ。
LINUXｺﾐｭの最大の欠点はﾎﾞﾗﾝﾀﾘな仕事に厳しすぎることじゃなかろか。
そしてそれは自分の首をぐりぐり締め付けることなのに。

>>831
逆。
reiserfsのメンテしてるのはNovellの数人だけだ、
って文句を垂れてたはず。

メンテナが嫌々やっているようなfsをつかいたくはないなぁ

それは言えるかも……

最も性能のいいﾗｲｻﾞｰを潰したがってる工作員がいるようだ

ハンス・レイザーの裁判費用の足しに募金したい。

PayPalとか受け付けてないのかな?

>>829
IntelにCPU、MSにOSで市場の主導権を奪われ、IBMは米国史上最高の赤字を出した
IBMは根本的に戦略を転換した
後にHDDやThnik Padを手放したように、開発から知的財産へシフトした
（システムインテグレータや特許等）

その過程でLinuxを実態以上に賞賛し、強力にプッシュしたんだよ
自らの戦略のために

>>839
その話JFSとの関係性を示してくれ。
まさか開発とまってないよね？

>>839
妄想は日記にかいとけよ。

>>839
>その過程でLinuxを実態以上に賞賛し、強力にプッシュしたんだよ
その過程でOS/2を見捨ててWindowsを強力にプッシュしたんだよ、が正しい。

e-businessとか言ってた頃は確かにLinuxを推してたよ
98、99年ころかな

>>842
>　その過程でOS/2を見捨ててWindowsを強力にプッシュしたんだよ、が正しい。

バカじゃない？
IBMとMSはOS/2を共同開発していたが、ケンカ別れになりMSはWindowsを出したんだが．．．

>>844
ルイス・ガースナー時代の話。

>>845
ルイス・ガースナーの話もあるんだが．．．
http://www-06.ibm.com/jp/linux/news/enterprise050912/index.shtml
>　IBMのLinuxへの取り組みは、
>　ルイス・ガースナー前会長の「将来の大きな部分を賭けている」という言葉のとおり、
>　世界規模で積極的な展開を見せる。

IBMの提灯はいくらでもみつかる

提灯てなんだ。Linuxのことか。それは>>839が書いてることか。

>その過程でOS/2を見捨てて
と
>IBMとMSはOS/2を共同開発していたが、ケンカ別れになりMSはWindowsを出したんだ
と時系列無視したレスの理由になるのか。

>>847
>　提灯てなんだ。Linuxのことか。それは>>839が書いてることか。

単にIBMの記事はLinux賞賛がやたら多いという意味だよ
>839の事は俺は知らん
が、大部分はhttp://ja.wikipedia.org/wiki/IBMからの盗用ではないかと思う

>　>その過程でOS/2を見捨てて
>　と
>　>IBMとMSはOS/2を共同開発していたが、ケンカ別れになりMSはWindowsを出したんだ
>　と時系列無視したレスの理由になるのか。

レスよく読めよ
お前さんの言うルイス・ガースナーがLinuxに「将来の大きな部分を賭けている」と言ったと
IBMの記事に書いてあるんだが．．．

>>848
俺は>>842でIBMのLinuxのことは否定的に書いている。

>お前さんの言うルイス・ガースナーがLinuxに「将来の大きな部分を賭けている」と言ったと
>IBMの記事に書いてあるんだが．．．
これと>>844にどんな関係があるんだ。

いい加減うんざりだよ
>846の俺がIBMのLinuxの事に対して肯定的な事ぐらいわかるだろう．．．

MSとケンカ別れし、Linuxに「将来の大きな部分を賭けている」IBMがなぜWindowsをプッシュしたんだ？
ソースを教えてくれ

>いい加減うんざりだよ
だったら
>バカじゃない？
こんな喧嘩売るようなレスするな。

>>850
巨額赤字解消のためOS/2を捨てWindowsをプッシュした。
Linuxは市場を作るところから始める必要があったが、Windowsの市場は既にあった。

>>851
ちょっと待てよ

>　巨額赤字解消のためOS/2を捨てWindowsをプッシュした。
>　Linuxは市場を作るところから始める必要があったが、Windowsの市場は既にあった。

俺はソースを教えてくれと言ったはずだ

何このスレ・・・？

>>853
IBMとLinuxとOS/2とほんの少しのファイルシステムのスレ

Windowsプッシュしたソースがでないので
俺はLinuxをプッシュしたソースを出す

WindowsからLinuxへのロードマップ
http://www-06.ibm.com/jp/developerworks/linux/031219/j_l-roadmap.html

Linux at IBM
http://www-03.ibm.com/linux/index.shtml

「IBMとLinuxとOS/2」は、これで集結ということで…

続きはLinuxで――IBM、OS/2の打ち切りを正式通告
http://www.itmedia.co.jp/enterprise/articles/0507/16/news013.html

集結してどうする

てかIBMのWindowsプッシュは売り言葉に買い言葉なだけでゎ？

>>857
>842,844
逆に向こうが売って俺が買ったんだよ

スレ違いだったのはすまん
もうこれで止める

ファイルシステムの構造を勉強したいんだが、何からスタートすれば良かろうか。

ソースを読め

にゃー

>>859
つ http://namesys.com

>>859
本屋行って関係ありそうな本を全て立ち読みして
一番わかりやすい本を買う。
そしてソース読みながら勉強しる。

なんか2.6.20-mm2のjfsの実装、おかしいかも。

いま恒例のext2/ext3/xfs/reiserfs/reiser4/jfs比較を
やっているのだけど、実機上でjfsのスコアが小ファイルベンチで
妙に遅い上、VMware上での比較でjfsはベンチマークツールが
応答しなくなってしまった。

マシン自体には問題なくアクセスできるのに、

$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 1 40 280044 45096 132024 0 0 43 87 8 5 0 1 3 96
0 1 40 280060 45096 132024 0 0 0 0 0 4 0 0 0 100
0 1 40 280060 45096 132024 0 0 0 10 3 3 0 0 0 100

でiowait 100%になったきり戻ってこない。他のfsでは数分で完了する
テストなのにjfsだけがこうなる。

>>864
まず非mm2の2.6.20で確認してから投げるべきでは？

http://d.hatena.ne.jp/mkouhei/searchdiary?word=*%5BLinux%5D
関係無いかもしれないが2.6.20とmmパッチについて書いてある

ん？mmパッチがダメなのかどうか切り分けしろってこと？
でも元々jfsはおまけで、reiser4を評価したかったというのが主目的なんで
ちょっと手が回らないかも。

まあ標準jfsはともかく、2.6.20-mm2の方のは何かおかしいよってことで（再現するし）。

>　ん？mmパッチがダメなのかどうか切り分けしろってこと？

まさにその通り
2.6.20-mm2がおかしいと投げただけでは誰も検証はしないと思う

LKMLに投げるわけじゃなし、久しぶりにファイルシステムのネタなんだから無問題だと思うが。

そもそも、VMWAREのバグに引っかかった可能性を考慮しなくていいのか？

>>868
別にLKMLに投げなくても、話題にするためには問題の切り分けが必要だろ
発言しただけで「さようなら」なら別だが

はあ? 解決するためには問題の切り分けが必要かもしれないけど
なんでネタにそんなのがいるんだよ。
お前部下のレポートか何かと勘違いしてないか?

気に触れた方がいらっしゃいます

>>871
お好きなようにネタにしてくれ
どのようなネタにするのか楽しみだよ

VMWareでやるとVMWare特有の問題なのかどうなのかわからないから困るよねえ。

切り分けしてからでないとネタになんないと思うんだけど。

「そんな現象起きたって言われても、実際どうなのか情報足りねえよ」と報告者の態度をネタにすることはアリと思うが。

それはお前がやってもいいんだぞ。

似たような問題に当たった人や解決した人がいないか、プローブを打っただけなんだろ。
で実際に困ってないなら、切り分けや検証なんてめんどくさくてやってらんないというのもわかる。
だいたい、手を動かさない奴が報告の批判をするのは筋違いだろう。
役に立たないなら流せばいいだろうに。

まあまあ
各位
ぐっとこらえて
つかあさい。

結論：reiserfsはクソ

>>877
>　だいたい、手を動かさない奴が報告の批判をするのは筋違いだろう。

俺はこのスレで>300で疑問を投げて検証は自分でやったよ
他のスレではもっと大規模な検証をやった

このスレの有用なレスは全部俺が書いたよ
他のスレではもっと神レベルの仕事をやった


いいかチミたち
これからは俺のことを唯一神又吉イエス(兄)と呼ぶように！

方法論じゃなくて、ファイルシステムの話しようぜ。

ネットワークファイルシステムになるけど、
gfs2 って面白そうだな。
どこかに導入手順のページ無いかな。

gfs興味はあるけどクラスタをどう作るの?
VMWare沢山立ち上げるとか?
それだとかなり意味ないし。

>>reiser4を評価したかったというのが主目的なんで
やはり、reiserfs に関わると頭がおかしくなるようだ。

ここまでボロクソに言われるのは正直きついですが、勉強になりました。
自分のレベルで書いていいようなスレでなかったようなので、すみません。

>>885
あなたはまったく悪くない。
誰もが暇を持て余してると勘違いしてるような基地外のいうことは便所の落書きと思って流してください。
匿名掲示板で万人にモラルや常識を求めるのは無理な話だから。

>>885
マジレスすると、「実装がおかしい」という言葉がまずかったと思うよ。
「挙動がおかしい」とか「動作が怪しい」ぐらいならともかく、
mm2を名指しして実装をどうこう言うなら、切り分けぐらい当然してると思われてもしょうがない。

ファイルシステム興味ない自分には過剰反応にしか見えないけど...
怖いスレだ。

VMWare上のパフォーマンス測定って俺的には全く興味ないけど
最近は重要なポイントなんだろうか。

あーあ、説教オヤジのせいで不具合報告が出にくくなった。

スレがあれるのはreiserfsのせい。

>>890
それはむしろ良いことだろう。

>>890
あれが不具合報告なら対応する人間は大変だな。

別にお前が対応するわけじゃないんだからガタガタ言うなよ。

>>981
いやならキーワードでアボーンしろ。

>>885
特に問題ないと思うけど、
>>864を読むと、できればjfsが2,6,20でokという確認は欲しかったかな。

mm2でおかしくなったという情報自体は有益で、
mm/jfsのMLとかBTSに入れておくのはいいと思う。

>>887
俺もそう思った。
がんばれよ >>885

この程度でボロクソに言われたとか、ガンバレとか信じられん。
デリケートすぎるよ。

日本教育では議論することを教えないからな。

多数の匿名から遠慮なくいわれると
自分が一方的にアホなのかと勘違いしちゃうんだよ。
論理的な反論にではなく人格的な中傷にやられる。
議論できるかどうかは関係ない。

議論に慣れていないから勘違いするんじゃないか?
相手の心理的に弱いところを突くのは立派な戦術だと思うが。

>>899
一体どのくらいひどい人格的な中傷があったというんだ？
具体的に指摘してもらえないか？
俺には２ｃｈの中では何ということもない部類にしか思えない。

すまん。よく読まずに適当なこと書いた。
流れ追ってみたらボロクソなんてところはまったくないな。
まあ>>899は2chの一般論ということで。

技術的な部分で突っ込めないのは、分からないからだけで
ただ、jfs問題を突き詰めるなら
mmの問題か、vmwareの問題かを切り分けた方がいいという指摘は間違いではない

で、jfsみんな使ってないから調べる気ない、と
俺は使ってるけど、取りあえず2.6.20に上げるのを辞めようと思ったくらいで・・・
困ってる人の人数は少ないのかな・・・・

どんな特殊な環境にせよ不具合報告は有用。
その後の分析やデバグはできる奴がやればいい。
報告者に負担を強いていてはコミュニティは有効に機能しないと思う。
俺は>>877に完全同意だ。
手を動かすつもりがないならスルーすればいい。>>865みたいなな態度は
周囲を萎縮させるだけ。

>>904
>>865は最後は「パッチ作ってから言えよ」くらいはいいそうだｗｗｗｗ
笑って流すだけだけどｗｗｗ

メモリ化けするPCで「動きません」って言われても迷惑なだけなんだけどな。

通常は、メモリ化けが無い事を前提にバグ報告とかがされるわけで・・・・


「暗黙の了解はわかりません」じゃなくて、
報告する際の前提条件は最低限理解しておいて欲しいな。

>>906
特殊な環境であることと、特殊な環境なことであることに触れずに
報告することをごっちゃにしてないか？

>>907
>906は特殊な環境のことには一切触れていない。

>>908
「メモリ化けするPC」→「特殊な環境」と理解したつもりだが。
でなければ、一体どういう文脈で>906が書かれたと思ってるのか？

>>909
>907は
「メモリ化けするPC」であることと、「メモリ化けするPC」であることに触れずに
報告することをごっちゃにしてないか？

こういう意味でいいんだな？
それは>906に対してどういう意見なのか説明してくれ。

そういう意見なわけだが。文脈を読もうという気がないの？

>>911
>906のどこが、「ごっちゃにしてないか？」と思うんだ？

>>912
>>906全体だが。そもそも>>906がどういう文脈で書かれたと思ってるんだい？

>>913
報告する際には自分の環境が正常であるという事が暗黙の前提である。
最低限その確認はしてから報告するべきだ。

こういう意味だと俺は思うが？
>906が何を「ごっちゃに」したのか俺には理解できないが。

お前が文脈を無視してレスしていることだけが分かった。
なんでメモリの話が唐突に出たのか推し量ろうという気はないのね。

>>915
俺には>>906に対する>>907のレスは説明が無い限り、理解できない。

わざわざ頭の悪いことをそんな高らかに主張してくれなくてもいいのに…。

通常じゃないときもそのことを明記しておけばいいってことじゃね？

>>918
俺は>>907のレスはそう受け取ったよ。
しかし、>>906へのレスになってないと思う。

いや、暗黙の了解を守れ（通常以外はだめ）と>>906は読めるから
>>906に対する>>907も意味はわかるよ。

>>920
自分の環境が正常でないと明記すればOKという事？
考えにくい報告かな。
からむつもりは無いのでご容赦を。

恐らく>907は暗に仮想PCの事を指していると思うんだが、
それなら堂々とそのように発言すべきだと思う

そんなことどうでもいいんだが...
と他の全員が思っているに一票。

>>923
まじ、すまんかった。

俺は面白かった。
>906-908を読むと皆VMwareを意識している。
ところがその話は>922まで誰も触れない。
狐と狸の化かしあいだな。

皆言葉足らずでワロタ

>>898
どっちの意味?
この頃の議論ごっこが糞だという意味なら同意。
揚げ足取りは国会中継だけで十分。

ともかく議論ごっこがしたい奴のために、隔離スレ作らないか?
そっちでやってくれよ。

マジレスすると
>906はVMwareのせいかどうかを切り分けろという内容を含んでいる。
それに対して
>907は動作環境はVMwareだと報告があるだろうと勇み足をしてしまった。
そこに
>908が>906はVMwareだとは言ってないだろうと注文をつけた。

勝者は何も発言しなかった>906だな。

で、jfs問題追及した人います？

それをやりたいと思う人がいると思いますか？

jfsって何でか話題にならないよねー。

決して劣ったファイルシステムではないのに、なんでだろう？

地味で話題性がないからでは？

頭がおかしくなる前にSolarisに移行すべし

俺もPPCでSolaris動くなら入れてるって。PPCだから・・・ただその一点が縛りなので・・・

蒸し返してスマソが、
>>906の「メモリ化けするPC」ってなんのこと？
メモリの内容が壊れる腐れPCのことか？

普通にメモリでデータ化けするPCという意味でない？
>>907も>>908も異議となえていないし。

NFSrootでディスクレスを一つ立ち上げているんだが、あるディレクトリツリーを
削除するのに、ディスクレスからやって一分、母艦からやって２，３秒なんだわ。

ネットワークファイルサービスに特化したFSってないんか？