ファイルシステム総合スレ その18

1 名前：login:Penguin mailto:sage [2017/12/28(木) 23:50:51.14 ID:/phfY+r1.net] ● 前スレ ファイルシステム総合スレ その17 mao.5ch.net/test/read.cgi/linux/1421502118/ ● 関連スレ ジャーナリングファイルシステム mevius.5ch.net/test/read.cgi/unix/979408065/ OpenSolaris/Illumos (OpenIndiana, etc.) 6 mevius.5ch.net/test/read.cgi/unix/1337411922/ FS関連スレ medaka.5ch.net/test/read.cgi/os/1137387538/ 過去スレ, 関連リンクは >>2-10 あたりで. 401 名前：login:Penguin mailto:sage [2019/06/26(水) 22:48:54.02 ID:6o+Ir3lv.net] >>393 > ページキャッシュはファイルシステムの機能ではないだろ ではないにしても最終的にこの人が弄ったのはfs/配下なんでしょ？ 何れにしてもそんなコアな部分を、nvmeの為に変更しますとか言ったら 揉めるのはしょうがない。 402 名前：login:Penguin mailto:sage [2019/06/26(水) 23:23:02.57 ID:OjXYcy1P.net] どちらかというと仮想メモリ周辺の話じゃないか 403 名前：login:Penguin mailto:sage [2019/06/26(水) 23:31:21.49 ID:6o+Ir3lv.net] 何にしても特定機能の為に汎用部分弄ったら怒られるのはしょうがない。 404 名前：login:Penguin mailto:sage [2019/06/27(木) 07:53:35.03 ID:1kwJgDpi.net] 非常に根本的が疑問があるんだが ダイレクトI/Oより遅いページキャッシュってなんか話がおかしくね ページキャッシュってオンメモリならストレージインターフェースより速いはずでは…？ 405 名前：login:Penguin mailto:sage [2019/06/27(木) 10:34:39.89 ID:j+m7QE0N.net] ページキャッシュが無い環境を使ったことがないから分からんな どうなんだろうな 406 名前：login:Penguin mailto:sage [2019/06/27(木) 13:32:07.45 ID:Va09TTiq.net] >>398 オンメモリでもページキャッシュの管理コストが絶対に発生するので 昔はストレージアクセスが文字通り桁違いに遅かったので管理コストは 無視しても差し支え無かったけど今はそうも言ってられなくなったってことかと 407 名前：login:Penguin [2019/06/27(木) 21:45:22.84 ID:icJgPc2A.net] ダイレクトIOが遅いって言ってるのは rawデバイスでDB扱うレベルの話でOK? でないとRAMがSSDに。ページキャッシュのコストがあるとはいえ遅いという話にはならんと思うんだが 408 名前：login:Penguin mailto:sage [2019/06/27(木) 22:50:29.23 ID:LI96p1HW.net] NVMeも通り越して、3DXpointだかあの辺のDRAMの数分の1くらいまで速いメモリを使うようになったら ページキャッシュ経由するより直で読み書きした方が良くね？って話ならまだわかるけど いくらNVMeでもフラッシュメモリ使っててページキャッシュはオーバーヘッドだからもう要らないみたいな話なら、何言ってんだお前…ってなる 409 名前：login:Penguin mailto:sage [2019/06/28(金) 17:51:59.02 ID:b8zcOuzC.net] jfs使てる人おらんの 410 名前：sage mailto:sage [2019/06/28(金) 18:01:49.33 ID:1jOqGt+U.net] >> 391 これって、次見るとわかるけど https://lkml.org/lkml/2019/6/14/127 要は、一般的な場合ではなくて、非常に大きくて（しかもアクセスパターン考えると）キャッシュになじまない ような大きなデータのときにはページキャッシュのオーバーヘッド大きい、また（そのような場合には） キャッシュに使うようなLRUみたいな汎用なアルゴリズムでなくてアプリケーションの方が素性が分かっているからそっちにキャッシュさせろと。 いうごく当たり前のこと言っている。しかも発言者は数字はだしてないが、多分９５％くらいのアプリケーションは 全然いまのページキャッシュでも問題ないということも言っている。 つまり　のこりの数値は私の感覚だが５％の大きなデータセットを使うDB（たとえばOracle)、big data crunchingとか の場合を話をしているわけで、どこを見るかですれ違いは無理もないかもしれないがなんだかな。 ページキャッシュの話を読んでて、次の話を思い出した。昔Sun Sparc V6だったか、bitblt 命令が入って、 白黒画面程度だったらCPUだけで簡単なウィンドウサポートができるようになった。 ただし、、MC６８Kなんかの場合にCPUだけでやって困ったのが、カラー画面の書き換えしただけで キャッシュが使われてしまって肝心のユーザアプリケーションのデータがキャッシュから追い出されることがある。 つまりカラー画面のデータって結構大きいので、そこを書き換えるとアプリケーションのデータがキャッシュから おいだされてしまうことがままある。 Sun Sparcの場合には、bitblt関係の命令っで使ったデータはキャッシュしないことで この問題を解決して、なるほどと思った。 巨大なデータセットがページキャッシュをバイパスするのも同じような話なんだけども、 なんでLinusは理性ある対話ができないのだろう？ 411 名前：login:Penguin mailto:sage [2019/06/28(金) 20:21:42.62 ID:GazpYCiw.net] 対話をする気がないか、諦めてるんじゃないの？ 412 名前：login:Penguin mailto:sage [2019/06/28(金) 20:40:28.14 ID:WA1on6xu.net] 流れを見てないからわからんけど これだけ見ると老害化してるやん 413 名前：login:Penguin mailto:sage [2019/06/28(金) 21:03:39.64 ID:KMXUlWzl.net] 最近の書込みキャッシュ付きの RAID コントローラだと、NVMe/SSD に対しては キャッシュを通さず直接書き込むほうが早いからそうしているらしい。 ちまちま4KBずつどのキャッシュを抹消していいかを計算しながらの、 ページテーブル書き換えながらの、だと本当に遅いんじゃないかね。 414 名前：login:Penguin mailto:sage [2019/06/28(金) 21:47:13.92 ID:UfcHNutv.net] 消去がボトルネックというなら納得かな 415 名前：login:Penguin mailto:sage [2019/06/29(土) 00:02:34.09 ID:aGo2YBvo.net] RAID-Zのオーバーヘッドが今一つ分からないわ…。 パリティ+1の倍数分のブロック単位で区切るから、無駄が出る事が有るよって事？ スプレッドシートの数式見てもピンと来ないぞ…。 block size in sectors …、in sector ってどゆこと？単純に使用するブロックの数？ https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz 416 名前：login:Penguin mailto:sage [2019/06/29(土) 11:34:54.48 ID:55acDkj4.net] >>409 block size in sectors はファイルシステム側のブロックサイズ(またはデータベースのブロックサイズ)で、 OSがファイルシステムに対して書き込むを要求する基本サイズだね。 in sectors は KB 単位じゃなくてセクタ単位で書きましたよ、この書き方ならブロックサイズ 512B の人も 4KB の人も同じ表で良いよね、ってだけじゃないかと。 417 名前：login:Penguin mailto:sage [2019/06/29(土) 11:46:31.18 ID:55acDkj4.net] 以下チラ裏。個人的解釈。 シートの Example にあるディスク７本のRAID-Z1を考える。 ブロックサイズ(プログラムやデータベースからの１度の書き込み要求のサイズ)が大きい場合は、 ディスク本数７−パリティ数(RAID-Z"1")＝６なので、基本６セクタごとにパリティ１セクタが付与される。 RAID-5 と違ってブロックサイズが６セクタ未満の場合はパリティが１セクタ付与されるだけ。 例えば３セクタならパリティ１個追加して４セクタ分書き込む。 RAID-5 なら６セクタ＋パリティ１個の７セクタ単位でしか書けない。 ただしRAID-Znは n+1 セクタ単位で書き込む必要があり、条件を満たさない場合は足りないセクタ分 パディングされる。 RAID-Z1 は n=1 なので書き込みセクタ数は２の倍数でなければならない。 なので２セクタ書き込む場合は、パリティ足して３セクタではなく４セクタ。 Example に戻って１度の書き込みのセクタ数が１６の場合、 セクタ1-6+パリティ + セクタ7-12+パリティ + セクタ13-16+パリティ の計19セクタ、n+1の倍数の制限でパディングが１セクタ追加されて総計20セクタ必要。 パリティとパディングは 20-16 で 4 セクタ。 データに対するパリティとパディングの比率は 4/16 で 25% になる。 418 名前：409 mailto:sage [2019/06/30(日) 00:08:50.88 ID:Iwm+1v/G.net] >>410-411 おお、ありがとう。データとの比率だったのね。スッキリしてきたよ。 最近ZFSについて調べ始めたのだが、いろいろと難しい…。 分かっていない所だらけなんだが、 ・>>in sectors は KB 単位じゃなくてセクタ単位で書きましたよ → 使用されたブロックの数という認識で良い？ ・ブロックと表現されているものは、NTFSで言うクラスタみたいなもん ・ブロックサイズは、4、8、16、32、64、128KBで可変（DBの人は8KBをセットする？） ・書き込まれるファイルのサイズによって、ブロックサイズとブロック数が変わってくる という事であってますか？ 419 名前：login:Penguin mailto:sage [2019/06/30(日) 03:37:15.39 ID:QfL+H/59.net] >>412 俺も ZFS についてはど素人なので下記内容については 420 名前：詳しい人による査読希望。 参照先の文脈においては、 (スプレッドシートの縦軸における)ブロック → 一回の書き込み量であってLinuxのファイルシステムのブロックサイズではない。 セクタ → ディスクに書き込む際の最小単位。 参照ページの２番目の図の P0 とか D0 の箱１個分。 セクタブロック → セクタと同義と解釈。 フィジカルブロックサイズ → セクタサイズと解釈。 (私見ではLinuxのファイルシステムの場合だと基本ブロック＝セクタ＝4KBなので厳密にどっちの話をしているか曖昧) だと解釈。 > ・>>in sectors は KB 単位じゃなくてセクタ単位で書きましたよ → 使用されたブロックの数という認識で良い？ 使用されたフィジカルブロック数という認識ですね。 > ・ブロックと表現されているものは、NTFSで言うクラスタみたいなもん Linux スレ的にはそう。 フィジカルブロックならそう。 スプレッドシートの文脈のブロックなら違う。 > ・ブロックサイズは、4、8、16、32、64、128KBで可変（DBの人は8KBをセットする？） フィジカルブロックサイズは固定。 > ・書き込まれるファイルのサイズによって、ブロックサイズとブロック数が変わってくる フィジカルブロックサイズは固定でブロック数だけ変わる。 zfs で動的ストライプ幅って言ってるのはフィジカルブロックサイズ(RAID装置によってはチャンクサイズって呼んでる部分) が動的に変化するのではなく、パリティグループ(データ＋パリティ,2番目の図の色が同じ箱のセット)の幅が動的ってだけ。 [] [ここ壊れてます] 421 名前：login:Penguin mailto:sage [2019/07/02(火) 01:12:51.76 ID:15r1RiO6.net] >>413 うーん…、頭がこんがらがってきた。 https://docs.oracle.com/cd/E19253-01/819-6260/gcfgv/index.html 「ブロックサイズが自動的に調整されます」というのは、何を指示している…？ 422 名前：login:Penguin mailto:sage [2019/07/02(火) 02:26:53.70 ID:vY+H/LKm.net] https://i.stack.imgur.com/G6Hxg.jpg https://i.stack.imgur.com/8z9mm.jpg genomewiki.ucsc.edu/images/f/f5/Xfs_filesystem_readWrite_performance.png genomewiki.ucsc.edu/images/f/f5/Xfs_filesystem_readWrite_performance.png genomewiki.ucsc.edu/images/a/a5/Btrfs_filesystem_readWrite_performance.png やはりext4が攻守最強か 423 名前：login:Penguin mailto:sage [2019/07/02(火) 02:32:52.56 ID:VNdE/qGn.net] パフォーマンスとかコストとかならそうなんだろうけど、 透過圧縮とか正当性の検証とかとなるとzfsのが上ってかext4じゃ無理 424 名前：login:Penguin mailto:sage [2019/07/02(火) 05:18:02.15 ID:FKCbYBRA.net] xfsは重複排除とCoWに逆マッピングも対応したのは聞いてたけど フォーマットの段階でオプション有効化する必要があったのか 今使ってるxfsとは全く別物だなこりゃ https://strugglers.net/~andy/blog/2017/01/10/xfs-reflinks-and-deduplication/ 425 名前：login:Penguin mailto:sage [2019/07/02(火) 07:23:04.59 ID:dV8XE8AH.net] 鯖屋は大変だな 俺みたいな一般人は黙ってext4使ってりゃいいんだろ？ 現状はそれで過不足ないし臨機応変に使うFSを吟味しろとかやってられん 426 名前：409 mailto:sage [2019/07/02(火) 07:59:51.04 ID:7tOiBm/F.net] >>414 > > ・ブロックサイズは、4、8、16、32、64、128KBで可変（DBの人は8KBをセットする？） > フィジカルブロックサイズは固定。 この文書からするとここが間違い(フィジカルブロックサイズは固定ではない)ですね。 元の文書でデータベース向けに 6KB に調整したってのがあるがそれがこれってことでしょう。 ソースを弄って調整した可能性もあったし、サイズが可変は間違いという話もあったので固定だと思っていました。 427 名前：login:Penguin mailto:sage [2019/07/02(火) 08:18:06.21 ID:7tOiBm/F.net] >>418 企業向けの大きいストレージは保守がハードとミドルウェアでセットになってないとNG。 加えて10年ぐらい前に luster や gluster fs, zfs ベースの製品が雨後の筍のように出てきたけど皆失敗した。 現状信頼されてるのは Isilon (OneFS) で、その下に NetApp (WAFL)。 HPE の 3PAR (AdaptiveFS?しらん) も評判下げずに続けてるようだ。 IBM の gpfs 使う製品もある。 言えるのは全てプロプラエタリで、オープンソース・フリーソフトの製品は企業は怖くて使ってられないみたいね。 なので鯖屋もストレージ屋に丸投げするしか仕事がないんじゃないかな。 428 名前：login:Penguin mailto:sage [2019/07/02(火) 18:13:16.85 ID:vY+H/LKm.net] オープンソースは 企業がバックにいないと話にならないよね そういう意味ではRedHatが公式に支えているxfsがベスト 429 名前：login:Penguin mailto:sage [2019/07/02(火) 20:23:04.94 ID:RJ/Pz5R6.net] 企業に支えられていないファイルシステムってどれのことだ？ 430 名前：login:Penguin mailto:sage [2019/07/02(火) 20:45:36.79 ID:CdZ1Kw09.net] プロプラ由来かOSS由来か…って事なんじゃね 431 名前：login:Penguin mailto:sage [2019/07/02(火) 21:28:31.67 ID:rRMzFXGI.net] Reiserfs 出所したから復活するってのは嘘だったのかな 432 名前：login:Penguin mailto:sage [2019/07/02(火) 22:16:53.32 ID:9meA9UgT.net] https://mao.5ch.net/test/read.cgi/linux/1557401718/ ↑ここから誘導されてきたファイルシステム素人なんですけど ext4が十分ではない場合って例えばどんな場合がありますか。 そしてext4では十分ではない場合にxfsやbtrfsを使えばその問題を解消できるんですかね。 ext4が対応できない問題って大抵のファイルシステムが対応できなさそうに思うんですけど……。 433 名前：login:Penguin mailto:sage [2019/07/02(火) 22:24:04.87 ID:+bA9GvGw.net] 個人利用なら今でもreiserfs有用だと思う あの早さが必要で諸々理解して使うなら reiser4fsの開発開始しないかなしないだろうな >>425 ext4遅い ext3よりreiserfsの方が倍くらい早いんじゃないか？という感動は忘れられん 434 名前：login:Penguin mailto:sage [2019/07/03(水) 00:05:11.18 ID:NZGhw/Gn.net] >>426 速度の問題があるんですね。 意識したことなかったです……。 バカな質問に答えてくださいありがとうございます。 435 名前：login:Penguin mailto:sage [2019/07/03(水) 00:53:08.95 ID:Qt/N9GEP.net] 今時パフォーマンスを最優先にするならF2FSでしょう reiserfsはもう相対的にそこまで早くもないし https://www.phoronix.com/scan.php?page=article&item=reiser4-linux-417&num=1 436 名前：login:Penguin mailto:sage [2019/07/03(水) 01:20:53.54 ID:ZZuB/vaR.net] そして障害時の対応で時間を食うと 437 名前：login:Penguin mailto:sage [2019/07/03(水) 01:22:02.01 ID:V5c8y5zy.net] >>425 >https://mao.5ch.net/test/read.cgi/linux/1557401718/ こういう人って zfs も LVM に乗せて LV リサイズしたら壊れたって騒ぐんだろうな 438 名前：login:Penguin mailto:sage [2019/07/03(水) 01:44:17.52 ID:E6xhFUOk.net] 用途にも寄るしな 安定性が課題のFSはテストならまだしも実用は怖い 個人デスクトップ用途だと小さめのファイル扱いはSSDだとそれほど差を感じないだろうが 大きなサイズの扱いはSSDでも時間かかる、これが早くなると体感がかなり違う とするとReiserFSは安定してるし、デスクトップ用途かなり良さそう 439 名前：login:Penguin mailto:sage [2019/07/03(水) 03:41:45.20 ID:v76vN8mT.net] そんな終わったFSを前提にされても 440 名前：login:Penguin mailto:sage [2019/07/03(水) 11:23:23.07 ID:lvGvaRtu.net] >>425 うちは透過圧縮が欲しいから/をbtrfsにしてる奴がある(ZFSはツリー外のモジュールとか面倒くさいしfuseも使いたくない) 早いCPU+遅いHDDの組み合わせでディスクアクセスがボトルネックになってるような環境だと結構目に見えて高速化されるよ ぼんやりとしか使ってないってのもあるけど3年ぐらい使ってて特にトラブルは無いな、まあデータを置こうとは思わんけど つかswapファイルに対応したりとか普通に開発継続してんのにRedHatが抜けたってだけで放置とか色々言ってるやつはアレやな 441 名前：login:Penguin mailto:sage [2019/07/03(水) 12:13:29.85 ID:Y5ON4Ylq.net] だってRed HatのAndy Grover様も Btrfsはメーリングリストが断末魔で埋め尽くされていてクソって言ってるんだもん https://strugglers.net/~andy/blog/2017/01/10/xfs-reflinks-and-deduplication/ 442 名前：login:Penguin [2019/07/03(水) 16:06:18.82 ID:IxUC1S3v.net] btrfsは互換性とか影響範囲とか考えずにどっかで再設計すれば違う展望もあっただろうになあｌ 443 名前：login:Penguin mailto:sage [2019/07/03(水) 20:49:55.88 ID:pn6xgYzw.net] 断末魔と団地妻って似てるな 444 名前：login:Penguin mailto:sage [2019/07/04(木) 08:58:47.97 ID:MPcWxAgH.net] btrfsの後釜になれるかもしれないbcachefsがそろそろLinuxカーネルのメインラインに入るぞ おそらく次かその次のバージョン 445 名前：login:Penguin mailto:sage [2019/07/04(木) 09:09:45.05 ID:5FppRmLC.net] メーリングリストが団地妻で埋め尽くされるとか股間が熱くなるな ファイルシステムが乱立ってのもなんだかなぁ zfsをパクって機能削減してxfsと足して２で割り切れない感じでいいと思うんだが 446 名前：login:Penguin mailto:sage [2019/07/04(木) 09:13:41.09 ID:t19oAjJ9.net] そういうお前も新しいの作ろうとしてんじゃん 447 名前：login:Penguin mailto:sage [2019/07/04(木) 10:30:19.24 ID:66v4UI/A.net] bcachefsのホームページ見たら 最初の一文からアレを意識しすぎぃぃぃ ＞We prioritize robustness and reliability over features and hype: ＞私達は機能と誇大宣伝よりも堅牢性と信頼性を優先します。 https://bcachefs.org/ 448 名前：login:Penguin mailto:sage [2019/07/04(木) 12:10:02.17 ID:rpGqPEX9.net] 究極たるzfsを崇めよ 449 名前：login:Penguin mailto:sage [2019/07/04(木) 15:51:02.60 ID:P64f5rak.net] >>440 先生！堅牢性と信頼性より機能と過大宣伝を優先したファイルシステムが多すぎてどれか特定できません！ 450 名前：login:Penguin mailto:sage [2019/07/04(木) 15:52:17.40 ID:P64f5rak.net] しかも https://mstdn.jp/@matsuu/100152722934755378 らしいし。 451 名前：login:Penguin mailto:sage [2019/07/04(木) 16:54:53.24 ID:+XLHt8Ha.net] >>443 そのベンチマークは1年前で古いこっちの最新の結果を見た方が良い https://www.phoronix.com/scan.php?page=article&item=bcachefs-linux-2019&num=1 XFS安定という結果には変わりないけど 452 名前：login:Penguin mailto:sage [2019/07/04(木) 17:09:39.55 ID:6XXEq2Nj.net] bcachefsは新しいけどベースがbcacheだからすでに信頼性はそれなりにありそう まだ使ったことないけど期待はしておく 453 名前：login:Penguin mailto:sage [2019/07/04(木) 17:18:29.96 ID:JEN2SxWZ.net] F2FSってフラッシュストレージ向けのくせに最近はHDDのサポートもしてきてるんだよな HDDで使うことはないだろうけど 454 名前：login:Penguin mailto:sage [2019/07/04(木) 19:12:45.96 ID:rpGqPEX9.net] 枯れてないFSなんて地雷やで 455 名前：login:Penguin mailto:sage [2019/07/04(木) 19:29:25.21 ID:1YidJb1m.net] そうは言ってもxfsも最近は新機能追加しまくりだし 枯れてるの定義は結構難しいぞ 456 名前：login:Penguin mailto:sage [2019/07/04(木) 20:03:25.18 ID:P64f5rak.net] MINIXファイルシステムを使おう！ 457 名前：login:Penguin mailto:sage [2019/07/04(木) 20:32:20.56 ID:z0Pbt8nE.net] 最強に安定しているのはntfs なお 458 名前：login:Penguin mailto:sage [2019/07/04(木) 20:53:14.61 ID:zNLNx3om.net] >>437 始まったな 459 名前：login:Penguin mailto:sage [2019/07/04(木) 22:44:03.98 ID:N/xMrX9J.net] windowsで安定してマウントできるファイルシステムは今はどれなんだ？ ext4ですらなんか怪しい感じなんだよなぁ 460 名前：login:Penguin mailto:sage [2019/07/04(木) 22:48:44.94 ID:JEN2SxWZ.net] >>452 btrfs 461 名前：login:Penguin mailto:sage [2019/07/04(木) 23:01:52.19 ID:nCIQ4/jH.net] >>452 ext2fs+ext4 これでだめだったらwindows窓から投げ捨てろ 462 名前：login:Penguin mailto:sage [2019/07/05(金) 00:04:02.89 ID:tcFjwaW7.net] wsl2が来るまで待て 463 名前：login:Penguin mailto:sage [2019/07/05(金) 00:10:18.86 ID:j7UvDQ62.net] 仮にntfsがオープンソースになってカーネルにマージされたら 互換性も考えてほぼ一択化になるだろうな 464 名前：login:Penguin mailto:sage [2019/07/05(金) 00:23:35.79 ID:G1guSEeh.net] >>454 ext2fsって開発が滞ってないか？ それに、環境によって、最新版だとマウントできないみたいだし。 実際自分のところもできなくて、いくつか戻す必要があった。 465 名前：login:Penguin mailto:sage [2019/07/05(金) 00:51:32.72 ID:w6qq3pqZ.net] ファイルシステムのシェアってどんなもんなんだろうな デバイス数では地味にF2FSが上位かもしれない 466 名前：login:Penguin mailto:sage [2019/07/05(金) 02:22:44.82 ID:54nYef5x.net] NTFSそれ自体の評価って高いの？ それともNTFSの概念や 467 名前：設計が評価できるの？ [] [ここ壊れてます] 468 名前：login:Penguin mailto:sage [2019/07/05(金) 02:40:31.93 ID:7kZq9gYf.net] ディスクのハード故障を除けばNTFSで致命的な状態に陥った経験は無いな 469 名前：login:Penguin mailto:sage [2019/07/05(金) 02:53:50.58 ID:q3JGl+2T.net] >>459 NTFSは特に良いところもなく、ファイル破損が良く起きる経験しかない 470 名前：login:Penguin mailto:sage [2019/07/05(金) 03:00:14.05 ID:j7UvDQ62.net] 全世界のPC初心者に有償で提供してるだけあって 少なくともWindows上ではクッソ安定してる Winを使ってるような層を相手に安定してるんだから異次元としか言い様がない 471 名前：login:Penguin mailto:sage [2019/07/05(金) 03:02:08.04 ID:q3JGl+2T.net] いやそういうの要らないから 対立煽りってやつ？ 472 名前：login:Penguin mailto:sage [2019/07/05(金) 04:11:17.66 ID:SYL5tGuC.net] 安定していると言ったら対立煽りに見える思考やばいだろ 473 名前：login:Penguin mailto:sage [2019/07/05(金) 05:35:22.47 ID:f3vjr6Xw.net] >>454 上手い事言ったつもりかｗ 474 名前：login:Penguin mailto:sage [2019/07/05(金) 06:48:52.45 ID:54nYef5x.net] >>462 なるほど。そういう見方もあるな。 Unixは基本的にファイルシステムをある程度理解してるから Windowsの大半の利用者みたいな使い方はしないわな。 その上で安定してるというのであればすごい。 でもそんなに安定してる？ 475 名前：login:Penguin mailto:sage [2019/07/05(金) 07:42:17.19 ID:q3JGl+2T.net] ntfsは電源断などのファイル破損が起こりやすいところとか 度々ext系ほかと比べられてるけど、同じ話ループしすぎなような 476 名前：login:Penguin mailto:sage [2019/07/05(金) 08:25:02.29 ID:54nYef5x.net] どうでもいいけどWikipediaのBrtFSの記事すっごく宣伝調だね…… 477 名前：login:Penguin mailto:sage [2019/07/05(金) 10:14:55.89 ID:lGHrYghR.net] >>459 https://togetter.com/li/346191 UbuntuJPの中の人曰く 478 名前：login:Penguin mailto:sage [2019/07/05(金) 12:10:41.83 ID:kGpLF8uq.net] ＞「今のLinuxにNTFSレベルにマトモなファイルシステムなぞない」 まで読んだ 479 名前：login:Penguin mailto:sage [2019/07/05(金) 12:25:54.82 ID:yalE+Jvn.net] アンチMSには理解し難いだろうけど、エンドユーザーが利用可能でよくメンテされて機能的にNTFS以上のファイルシステムってちょっと思いつけない、あるなら例示して？…ってなるな。 ああ、「俺の好きなFS」じゃないんで。まあ言っても理解できないだろうが… もちろんWindowsから扱う場合の話で、互換環境で同等の信頼性があるとは思えんが。 それでもUFSやextよりはずっとマシ 480 名前：login:Penguin mailto:sage [2019/07/05(金) 12:26:03.28 ID:8tR6yfC3.net] そういえばBSDのハマー2の評価はどうなの？ 481 名前：login:Penguin mailto:sage [2019/07/05(金) 12:28:53.02 ID:yalE+Jvn.net] Linux環境だと、データセンター並みに巨大なボリュームを扱うとか、ウェアレベリングの無いフラッシュメモリをストレージにする組み込みみたいな特殊用途でない個人ユースなら、消去法でext4が無難か… 482 名前：login:Penguin mailto:sage [2019/07/05(金) 12:30:53.10 ID:yalE+Jvn.net] >>468 たまにあるよね、読者を説得というか、折伏？しようとしてる記事。 483 名前：!ninja mailto:sage [2019/07/05(金) 12:40:54.45 ID:rX9H6RAi.net] デスクトップとしてLinuxを使用して写真の現像とか色々しているけれど ext4で問題になった事はないです。(安定しています) 因みにWindowsはカメラのファームアップとOSアップデート位しか使わない。 484 名前：login:Penguin mailto:sage [2019/07/05(金) 14:25:39.16 ID:qDrdSQQO.net] 別に個人が普通に使うならどれでも滅多に困らない 485 名前：login:Penguin mailto:sage [2019/07/05(金) 17:01:26.55 ID:5Oj7dNKU.net] 外付けHDDをLinuxで使う場合、 FAT32は無いものとして、 NTFSとexFAT、どちらのほうが無難？ 486 名前：login:Penguin mailto:sage [2019/07/05(金) 17:18:10.07 ID:aHzpu2WI.net] 外付けHDDだってことは、複数のOSからmountすることもあるだろうから exFATが無難というか最良かと 487 名前：login:Penguin mailto:sage [2019/07/05(金) 17:29:29.45 ID:0uxDVNFV.net] >>472 Dragonf 488 名前：lyBSD使てる日本人は居らん [] [ここ壊れてます] 489 名前：login:Penguin mailto:sage [2019/07/05(金) 23:39:13.82 ID:QVfQ7xAQ.net] COWありでまともに使えるファイルシステムはどれなんだー 490 名前：login:Penguin mailto:sage [2019/07/06(土) 00:04:47.81 ID:8LM9xkHS.net] xfsでしょそりゃ ただしフォーマットし直さないとCoWは有効化出来ないけど 491 名前：login:Penguin mailto:sage [2019/07/06(土) 04:51:15.15 ID:g9aj4tWg.net] xfsのcowってまともに使えるのか？ 最近使えるようになったばかりだろ 新しいファイルシステムと同じようなもの 492 名前：login:Penguin mailto:sage [2019/07/06(土) 04:59:40.34 ID:8LM9xkHS.net] xfsのメンテナが自分のPCで CoW導入で使えるようになった 新機能の重複排除を使ってると言ってるのだから安心していいかと 493 名前：login:Penguin mailto:sage [2019/07/06(土) 05:20:44.07 ID:VaeT5YKG.net] そりゃファイルシステムのメンテナなら自分のPCで動かしてて当然だろうな 494 名前：login:Penguin mailto:sage [2019/07/06(土) 05:27:27.89 ID:L3XPzqxa.net] 俺はbtrfsのメンテナがbtrfsを常用しているとは思えない 495 名前：login:Penguin mailto:sage [2019/07/06(土) 05:32:05.88 ID:g9aj4tWg.net] 常用してなくても動かしてはいるだろ 496 名前：login:Penguin mailto:sage [2019/07/06(土) 07:08:26.31 ID:JWtFUONt.net] btrfsのお陰でニュースサイトは信用ならないものだということを再認識した ボラクルの政治力（）がそれをさせたのだろうか、それとも 497 名前：login:Penguin mailto:sage [2019/07/06(土) 07:10:44.85 ID:dmxILAE/.net] >>487 BrtFSってオラクル噛んでんの？ 498 名前：login:Penguin mailto:sage [2019/07/06(土) 07:54:59.98 ID:RB1jb8Q5.net] 「btrfsは透過圧縮が凄い！！」 みたいな宣伝ならまだ分かる。 実際には 「btrfsは他のFSよりも堅牢！安全！」 みたいに、大事なデータこそbtrfsみたいな言い方してるからタチが悪い 。 499 名前：login:Penguin mailto:sage [2019/07/06(土) 08:17:26.52 ID:JWtFUONt.net] >>488 RedHatだったか？ 500 名前：login:Penguin mailto:sage [2019/07/06(土) 11:46:12.10 ID:4pSPVA6e.net] >>483 ストレージなんて導入後１年とか経過したら急激にパフォーマンスが悪化したみたいな話は少なくないわけで。 データ置くんだから色々なハード×運用アプリ×負荷条件×期間で運用して実績積んだ上じゃないと安心 なんてとても言えないんじゃ。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef