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の酷さは相変わらずだよな。