ファイルシステム総合スレ その18
■ このスレッドは過去ログ倉庫に格納されています
改心したはずのトーバルズ氏がまたもや感情的な暴言
Liam Tung （Special to ZDNet.com） 翻訳校正： 編集部 2019年06月25日 12時28分
https://japan.zdnet.com/article/35138967/
(前略) Torvalds氏に早速かんしゃくの矛先を向けられたのは、オーストラリア人プロ
グラマーのDave Chinner氏である。Chinner氏は、多くのLinuxディストリビューションが
サポートしているSilicon Graphics製のXFSファイルシステムを管理している。(中略)
しかしTorvalds氏は、Chinner氏の言い分を否定し、そのような考えを広めようと
している開発者は「無能だ」と痛烈に批判した。
「Dave、キャッシュはちゃんと機能する。そう思わない者は無能なだけだ。ファイル
システムによるアクセスの99％はキャッシュに保存され、IOを行うことは決してない。
ページキャッシュはファイルシステムを美しく処理している」（Torvalds氏）
それに対してChinner氏は、Linuxの行動規範に従い「礼儀正しく議論する」ことをリマイ
ンドし、カーネル開発者がプロらしく論議できる雰囲気を作ろうと、次のように回答した。
「その通りだ。ページキャッシュは多くのストレージより高速なため、問題なく機能する
ケースはたくさんある。しかし、私が指摘したのは、そのことではない」「わたしが、IOの
並行処理、ページキャッシュ、既存コードのアーキテクチャー上の不具合などについて書い
た長文のメールの中から、たった1つの記述を前後関係を無視して引用し、まったく新しい
文脈をでっちあげた上で、私がキャッシュやページキャッシュのことを全く理解していない
と非難し始めた。」「プロらしからぬ振る舞いだ。しかし残念ながら、まったく予測できた
反応だとしか言いようがない」とChinner氏は応じている。 >>391
>ページキャッシュはいまも、ダイレクトIOよりかなりスピードが遅い。そしてNVMeのSSDが高速になればなるほど、
>そのギャップは広くなりつつある。PCIe 4のSSDで、この問題はますます明白になるだろう。もはやページキャッシュを
>使用する理由は、旧態依然としたディスクストレージを使う手頃な価格のシステムやmmap() をサポートするためだけになりつつある
じゃあnvme用に新しいファイルシステム考えれば良いんじゃね？って気はするけどね。
磁気ディスクを前提としたファイルシステムIOいじって喧嘩するなよｗｗ 何言ってんだ
ページキャッシュはファイルシステムの機能ではないだろ >>393
> ページキャッシュはファイルシステムの機能ではないだろ
ではないにしても最終的にこの人が弄ったのはfs/配下なんでしょ？
何れにしてもそんなコアな部分を、nvmeの為に変更しますとか言ったら
揉めるのはしょうがない。 何にしても特定機能の為に汎用部分弄ったら怒られるのはしょうがない。 非常に根本的が疑問があるんだが
ダイレクトI/Oより遅いページキャッシュってなんか話がおかしくね
ページキャッシュってオンメモリならストレージインターフェースより速いはずでは…？ ページキャッシュが無い環境を使ったことがないから分からんな
どうなんだろうな >>398
オンメモリでもページキャッシュの管理コストが絶対に発生するので
昔はストレージアクセスが文字通り桁違いに遅かったので管理コストは
無視しても差し支え無かったけど今はそうも言ってられなくなったってことかと ダイレクトIOが遅いって言ってるのは
rawデバイスでDB扱うレベルの話でOK?
でないとRAMがSSDに。ページキャッシュのコストがあるとはいえ遅いという話にはならんと思うんだが NVMeも通り越して、3DXpointだかあの辺のDRAMの数分の1くらいまで速いメモリを使うようになったら
ページキャッシュ経由するより直で読み書きした方が良くね？って話ならまだわかるけど
いくらNVMeでもフラッシュメモリ使っててページキャッシュはオーバーヘッドだからもう要らないみたいな話なら、何言ってんだお前…ってなる >> 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は理性ある対話ができないのだろう？ 流れを見てないからわからんけど
これだけ見ると老害化してるやん 最近の書込みキャッシュ付きの RAID コントローラだと、NVMe/SSD に対しては
キャッシュを通さず直接書き込むほうが早いからそうしているらしい。
ちまちま4KBずつどのキャッシュを抹消していいかを計算しながらの、
ページテーブル書き換えながらの、だと本当に遅いんじゃないかね。 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 >>409
block size in sectors はファイルシステム側のブロックサイズ(またはデータベースのブロックサイズ)で、
OSがファイルシステムに対して書き込むを要求する基本サイズだね。
in sectors は KB 単位じゃなくてセクタ単位で書きましたよ、この書き方ならブロックサイズ 512B の人も
4KB の人も同じ表で良いよね、ってだけじゃないかと。 以下チラ裏。個人的解釈。
シートの 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% になる。 >>410-411
おお、ありがとう。データとの比率だったのね。スッキリしてきたよ。
最近ZFSについて調べ始めたのだが、いろいろと難しい…。
分かっていない所だらけなんだが、
・>>in sectors は KB 単位じゃなくてセクタ単位で書きましたよ → 使用されたブロックの数という認識で良い？
・ブロックと表現されているものは、NTFSで言うクラスタみたいなもん
・ブロックサイズは、4、8、16、32、64、128KBで可変（DBの人は8KBをセットする？）
・書き込まれるファイルのサイズによって、ブロックサイズとブロック数が変わってくる
という事であってますか？ >>412
俺も ZFS についてはど素人なので下記内容については詳しい人による査読希望。
参照先の文脈においては、
(スプレッドシートの縦軸における)ブロック → 一回の書き込み量であってLinuxのファイルシステムのブロックサイズではない。
セクタ → ディスクに書き込む際の最小単位。 参照ページの２番目の図の P0 とか D0 の箱１個分。
セクタブロック → セクタと同義と解釈。
フィジカルブロックサイズ → セクタサイズと解釈。
(私見ではLinuxのファイルシステムの場合だと基本ブロック＝セクタ＝4KBなので厳密にどっちの話をしているか曖昧)
だと解釈。
> ・>>in sectors は KB 単位じゃなくてセクタ単位で書きましたよ → 使用されたブロックの数という認識で良い？
使用されたフィジカルブロック数という認識ですね。
> ・ブロックと表現されているものは、NTFSで言うクラスタみたいなもん
Linux スレ的にはそう。 フィジカルブロックならそう。 スプレッドシートの文脈のブロックなら違う。
> ・ブロックサイズは、4、8、16、32、64、128KBで可変（DBの人は8KBをセットする？）
フィジカルブロックサイズは固定。
> ・書き込まれるファイルのサイズによって、ブロックサイズとブロック数が変わってくる
フィジカルブロックサイズは固定でブロック数だけ変わる。
zfs で動的ストライプ幅って言ってるのはフィジカルブロックサイズ(RAID装置によってはチャンクサイズって呼んでる部分)
が動的に変化するのではなく、パリティグループ(データ＋パリティ,2番目の図の色が同じ箱のセット)の幅が動的ってだけ。 パフォーマンスとかコストとかならそうなんだろうけど、
透過圧縮とか正当性の検証とかとなるとzfsのが上ってかext4じゃ無理 xfsは重複排除とCoWに逆マッピングも対応したのは聞いてたけど
フォーマットの段階でオプション有効化する必要があったのか
今使ってるxfsとは全く別物だなこりゃ
https://strugglers.net/~andy/blog/2017/01/10/xfs-reflinks-and-deduplication/ 鯖屋は大変だな
俺みたいな一般人は黙ってext4使ってりゃいいんだろ？
現状はそれで過不足ないし臨機応変に使うFSを吟味しろとかやってられん >>414
> > ・ブロックサイズは、4、8、16、32、64、128KBで可変（DBの人は8KBをセットする？）
> フィジカルブロックサイズは固定。
この文書からするとここが間違い(フィジカルブロックサイズは固定ではない)ですね。
元の文書でデータベース向けに 6KB に調整したってのがあるがそれがこれってことでしょう。
ソースを弄って調整した可能性もあったし、サイズが可変は間違いという話もあったので固定だと思っていました。 >>418
企業向けの大きいストレージは保守がハードとミドルウェアでセットになってないとNG。
加えて10年ぐらい前に luster や gluster fs, zfs ベースの製品が雨後の筍のように出てきたけど皆失敗した。
現状信頼されてるのは Isilon (OneFS) で、その下に NetApp (WAFL)。
HPE の 3PAR (AdaptiveFS?しらん) も評判下げずに続けてるようだ。 IBM の gpfs 使う製品もある。
言えるのは全てプロプラエタリで、オープンソース・フリーソフトの製品は企業は怖くて使ってられないみたいね。
なので鯖屋もストレージ屋に丸投げするしか仕事がないんじゃないかな。 オープンソースは
企業がバックにいないと話にならないよね
そういう意味ではRedHatが公式に支えているxfsがベスト 企業に支えられていないファイルシステムってどれのことだ？ Reiserfs
出所したから復活するってのは嘘だったのかな https://mao.5ch.net/test/read.cgi/linux/1557401718/
↑ここから誘導されてきたファイルシステム素人なんですけど
ext4が十分ではない場合って例えばどんな場合がありますか。
そしてext4では十分ではない場合にxfsやbtrfsを使えばその問題を解消できるんですかね。
ext4が対応できない問題って大抵のファイルシステムが対応できなさそうに思うんですけど……。 個人利用なら今でもreiserfs有用だと思う
あの早さが必要で諸々理解して使うなら
reiser4fsの開発開始しないかなしないだろうな
>>425
ext4遅い
ext3よりreiserfsの方が倍くらい早いんじゃないか？という感動は忘れられん >>426
速度の問題があるんですね。
意識したことなかったです……。
バカな質問に答えてくださいありがとうございます。 今時パフォーマンスを最優先にするならF2FSでしょう
reiserfsはもう相対的にそこまで早くもないし
https://www.phoronix.com/scan.php?page=article&;item=reiser4-linux-417&num=1 用途にも寄るしな
安定性が課題のFSはテストならまだしも実用は怖い
個人デスクトップ用途だと小さめのファイル扱いはSSDだとそれほど差を感じないだろうが
大きなサイズの扱いはSSDでも時間かかる、これが早くなると体感がかなり違う
とするとReiserFSは安定してるし、デスクトップ用途かなり良さそう >>425
うちは透過圧縮が欲しいから/をbtrfsにしてる奴がある(ZFSはツリー外のモジュールとか面倒くさいしfuseも使いたくない)
早いCPU+遅いHDDの組み合わせでディスクアクセスがボトルネックになってるような環境だと結構目に見えて高速化されるよ
ぼんやりとしか使ってないってのもあるけど3年ぐらい使ってて特にトラブルは無いな、まあデータを置こうとは思わんけど
つかswapファイルに対応したりとか普通に開発継続してんのにRedHatが抜けたってだけで放置とか色々言ってるやつはアレやな だってRed HatのAndy Grover様も
Btrfsはメーリングリストが断末魔で埋め尽くされていてクソって言ってるんだもん
https://strugglers.net/~andy/blog/2017/01/10/xfs-reflinks-and-deduplication/ btrfsは互換性とか影響範囲とか考えずにどっかで再設計すれば違う展望もあっただろうになあｌ btrfsの後釜になれるかもしれないbcachefsがそろそろLinuxカーネルのメインラインに入るぞ
おそらく次かその次のバージョン メーリングリストが団地妻で埋め尽くされるとか股間が熱くなるな
ファイルシステムが乱立ってのもなんだかなぁ
zfsをパクって機能削減してxfsと足して２で割り切れない感じでいいと思うんだが bcachefsのホームページ見たら
最初の一文からアレを意識しすぎぃぃぃ
＞We prioritize robustness and reliability over features and hype:
＞私達は機能と誇大宣伝よりも堅牢性と信頼性を優先します。
https://bcachefs.org/ >>440
先生！堅牢性と信頼性より機能と過大宣伝を優先したファイルシステムが多すぎてどれか特定できません！ >>443
そのベンチマークは1年前で古いこっちの最新の結果を見た方が良い
https://www.phoronix.com/scan.php?page=article&;item=bcachefs-linux-2019&num=1
XFS安定という結果には変わりないけど bcachefsは新しいけどベースがbcacheだからすでに信頼性はそれなりにありそう
まだ使ったことないけど期待はしておく F2FSってフラッシュストレージ向けのくせに最近はHDDのサポートもしてきてるんだよな
HDDで使うことはないだろうけど そうは言ってもxfsも最近は新機能追加しまくりだし
枯れてるの定義は結構難しいぞ windowsで安定してマウントできるファイルシステムは今はどれなんだ？
ext4ですらなんか怪しい感じなんだよなぁ >>452
ext2fs+ext4
これでだめだったらwindows窓から投げ捨てろ 仮にntfsがオープンソースになってカーネルにマージされたら
互換性も考えてほぼ一択化になるだろうな >>454
ext2fsって開発が滞ってないか？
それに、環境によって、最新版だとマウントできないみたいだし。
実際自分のところもできなくて、いくつか戻す必要があった。 ファイルシステムのシェアってどんなもんなんだろうな
デバイス数では地味にF2FSが上位かもしれない NTFSそれ自体の評価って高いの？
それともNTFSの概念や設計が評価できるの？ ディスクのハード故障を除けばNTFSで致命的な状態に陥った経験は無いな >>459
NTFSは特に良いところもなく、ファイル破損が良く起きる経験しかない 全世界のPC初心者に有償で提供してるだけあって
少なくともWindows上ではクッソ安定してる
Winを使ってるような層を相手に安定してるんだから異次元としか言い様がない 安定していると言ったら対立煽りに見える思考やばいだろ >>462
なるほど。そういう見方もあるな。
Unixは基本的にファイルシステムをある程度理解してるから
Windowsの大半の利用者みたいな使い方はしないわな。
その上で安定してるというのであればすごい。
でもそんなに安定してる？ ntfsは電源断などのファイル破損が起こりやすいところとか
度々ext系ほかと比べられてるけど、同じ話ループしすぎなような どうでもいいけどWikipediaのBrtFSの記事すっごく宣伝調だね…… ＞「今のLinuxにNTFSレベルにマトモなファイルシステムなぞない」
まで読んだ アンチMSには理解し難いだろうけど、エンドユーザーが利用可能でよくメンテされて機能的にNTFS以上のファイルシステムってちょっと思いつけない、あるなら例示して？…ってなるな。
ああ、「俺の好きなFS」じゃないんで。まあ言っても理解できないだろうが…
もちろんWindowsから扱う場合の話で、互換環境で同等の信頼性があるとは思えんが。
それでもUFSやextよりはずっとマシ Linux環境だと、データセンター並みに巨大なボリュームを扱うとか、ウェアレベリングの無いフラッシュメモリをストレージにする組み込みみたいな特殊用途でない個人ユースなら、消去法でext4が無難か… >>468
たまにあるよね、読者を説得というか、折伏？しようとしてる記事。 デスクトップとしてLinuxを使用して写真の現像とか色々しているけれど
ext4で問題になった事はないです。(安定しています)
因みにWindowsはカメラのファームアップとOSアップデート位しか使わない。 外付けHDDをLinuxで使う場合、
FAT32は無いものとして、
NTFSとexFAT、どちらのほうが無難？ 外付けHDDだってことは、複数のOSからmountすることもあるだろうから
exFATが無難というか最良かと >>472
DragonflyBSD使てる日本人は居らん COWありでまともに使えるファイルシステムはどれなんだー xfsでしょそりゃ
ただしフォーマットし直さないとCoWは有効化出来ないけど xfsのcowってまともに使えるのか？
最近使えるようになったばかりだろ
新しいファイルシステムと同じようなもの xfsのメンテナが自分のPCで
CoW導入で使えるようになった
新機能の重複排除を使ってると言ってるのだから安心していいかと そりゃファイルシステムのメンテナなら自分のPCで動かしてて当然だろうな 俺はbtrfsのメンテナがbtrfsを常用しているとは思えない btrfsのお陰でニュースサイトは信用ならないものだということを再認識した
ボラクルの政治力（）がそれをさせたのだろうか、それとも 「btrfsは透過圧縮が凄い！！」
みたいな宣伝ならまだ分かる。
実際には
「btrfsは他のFSよりも堅牢！安全！」
みたいに、大事なデータこそbtrfsみたいな言い方してるからタチが悪い 。 ■ このスレッドは過去ログ倉庫に格納されています
