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

**login:Penguin** · 2017/12/28(木) 23:50:51.14

● 前スレ
ファイルシステム総合スレその17
http://mao.5ch.net/test/read.cgi/linux/1421502118/

● 関連スレ
ジャーナリングファイルシステム
http://mevius.5ch.net/test/read.cgi/unix/979408065/

OpenSolaris/Illumos (OpenIndiana, etc.) 6
http://mevius.5ch.net/test/read.cgi/unix/1337411922/

FS関連スレ
http://medaka.5ch.net/test/read.cgi/os/1137387538/
過去スレ, 関連リンクは >>2-10 あたりで.

**login:Penguin** · 2019/09/12(木) 08:02:48.44

素直にXFS使っとけ

**login:Penguin** · 2019/09/12(木) 14:07:40.59

XFSは多機能すぎて誰も使いこなせない

**login:Penguin** · 2019/09/13(金) 10:02:05.12

LinuxのXFSにもGRIOあるのかなぁ

**login:Penguin** · 2019/09/15(日) 08:26:10.55

EROFSがLinux5.4でメインライン入りするらしい
リードオンリーファイルシステムだから使いどころは限られるが
すでにスマホで動いているので実績はある

**login:Penguin** · 2019/09/15(日) 09:51:04.18

え、エロFS……

**login:Penguin** · 2019/09/15(日) 13:31:08.77

エッチFS!

**login:Penguin** · 2019/09/15(日) 17:37:09.38

>>743
何で圧縮は無いの？

**login:Penguin** · 2019/09/16(月) 01:54:38.69

huawaiのスマホのsystemパーティションでEROFS使われてるのか
androidのsystemは元々リードオンリーでマウントされてたから有用だろうな

**login:Penguin** · 2019/09/16(月) 21:49:59.06

くだらない質問で恐縮なのだが、
既存の、RW可能なファイルシステムで作成したボリュームをROでマウントするのはわかる。

しかしリードオンリーのファイルシステムとなると、
マウントするボリュームは、一体どのような手段で作成されるのだろうか？

卵が先か、鶏が先か…

**login:Penguin** · 2019/09/16(月) 22:16:57.15

>>750
.iso (ISO9660 ファイルシステム、DVD-ROM 等に使われるリードオンリーのファイルシステム)
ファイル作ったことないですかそうですか

**login:Penguin** · 2019/09/16(月) 22:20:45.35

>>750
別のファイルシステムから変換するのでは？
少なくともISO9660はそういう感じだよね。

原理的に、仕様がわかっていて、どういう風にファイルを用意したいか決まっていれば、
ビット列は生成可能なのだから、鶏が先か、卵が先かという問題ではないような気がするけど。

**login:Penguin** · 2019/09/16(月) 22:23:33.54

erofs-utilsに入っているmkfs.erofsで作るらしい

ttps://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/tree/README

**login:Penguin** · 2019/09/17(火) 00:23:24.54

>>750
いや、roなファイルシステムも使用時にroでマウントしてるだけで
作成時はイメージファイル上にFSを作ってrwマウントしてファイルコピーするだけ

**login:Penguin** · 2019/09/17(火) 02:01:04.20

>>753
圧縮の有無に違いはあるけど、使い方はSquashFSみたいな感じらしい

**login:Penguin** · 2019/09/17(火) 09:41:47.16

>>754
なるほど，まあ当然っちゃ当然そうだよな。

**login:Penguin** · 2019/09/17(火) 12:22:17.37

>>754
isofsはwrite()が実装されてないらしいし、rwマウントしてコピーってのはちょっと違うのでは？

**login:Penguin** · 2019/09/17(火) 21:24:20.70

fuseとかでrwマウント出来るようにした物はあるだろうけど、最初からrwでマウント出来たらroファイルシステムじゃないだろｗ

**login:Penguin** · 2019/09/17(火) 22:27:12.02

ro専用のファイルシステムって、誰が書き込むの？

**login:Penguin** · 2019/09/17(火) 22:50:56.62

mkfsが｢XXバイト目にマジックナンバー書き込んでYYバイト目にはこのフラグの値書き込んで｣みたいにやってる時に一緒にファイルも書き込むだけ

**login:Penguin** · 2019/09/21(土) 04:11:32.07

これでZFSの重複排除が実用的になるだろうか？
まともに使えそうなら革命的だが
https://www.phoronix.com/scan.php?page=news_item&;px=OpenZFS-Better-Dedup

**login:Penguin** · 2019/09/21(土) 23:27:31.72

重複排除なんてバックグラウンドでやればいいだけじゃないの？

**login:Penguin** · 2019/09/22(日) 05:53:45.18

今時のバックアップソフトや専用NASはリアルタイムに重複排除出来る

**login:Penguin** · 2019/09/30(月) 15:09:29.89

>>762
重複するデータが既にストレージ上に存在するのなら後続の書き込みは行われないのが理想

**login:Penguin** · 2019/10/01(火) 01:58:35.48

>>764
コピーするときだけで十分だろ
どうせ上書きしたら内容は変わるんだし

**login:Penguin** · 2019/10/01(火) 02:38:11.33

重複データは書き込み時に判定というのは実際どう判定するのか
書き込み前に一度ファイルを舐めて双方のハッシュでも比較するのか、すごい手間だな
そんなものシステムワイドでファイル作成時や最終書き込みの時にハッシュ引いてファイルの属性データの方に持たせておけばいいのに
それでもハッシュの衝突とか無いとも限らないしな…どうやって検出すればいいんだ

…などと考え始めると眠れなくなる

**login:Penguin** · 2019/10/01(火) 03:54:30.13

うん、だからバックアップでやればいいんじゃねーのって思ってる
最終的にはファームウェア側で実装するのもありかもね

**login:Penguin** · 2019/10/01(火) 04:01:48.13

>>766
ファイルレベルでハッシュ比較しても駄目だよ。
少しデータが変わっただけの巨大なファイルで重複排除ができなくなる。

でもまあそういう例って仮想イメージのスナップショットぐらいしか無いんだよねｗ
んで、仮想イメージは仮想マシン側がスナップショットを差分で保存してくれるから関係ない

ファイルレベルならバックグラウンドでファイル検索して
ファイルサイズが同じ→中身を比較→全部一緒ならハードリンクにする
これだけで十分だろう

**login:Penguin** · 2019/10/01(火) 04:34:23.91

ログファイルとか重複排除すると効果大きいんだけどな
一般家庭の用途だとストレージのほとんどがメディアファイルで埋まるから効果薄いよね

**login:Penguin** · 2019/10/01(火) 08:13:43.35

>>769
なんで同じ内容のログファイルが
大量にできるんだ？

圧縮ならまだしも何の意味もないだろ

**login:Penguin** · 2019/10/01(火) 08:17:03.18

Windowsは95の時代からドライブの圧縮機能があって
昔はお世話になったもんだが、他のファイルシステムには
そういう機能あるのかな？

**login:Penguin** · 2019/10/01(火) 10:03:19.94

>>770
そもそもファイル単位という前提が間違ってる

**login:Penguin** · 2019/10/01(火) 10:26:58.35

>>772
ブロック単位とか言いたいんだろうが、何単位であっても
ログファイルなんて同じ内容にはまずならんだろうが

1バイト違っていたりアドレスがずれてるだけでも
だけでも違うものと判断されるんだからさ

**login:Penguin** · 2019/10/01(火) 22:11:05.16

ZFS とか重複排除はかなりメモリ食うらしいね

NTFS は指定日数経過後のファイルに対してだけ実行するとか
バックグラウンドで実行/高負荷時には実行しないとか
使用メモリ制限とか色々オプションがあるみたい

モードも一般/VDI/バックアップと用途向けに用意されてる
中小規模、ホームユースで考えると NTFS の方式はわかりやすくて
かつ優秀だと思う

**login:Penguin** · 2019/10/01(火) 22:33:23.76

確かNTFSの重複排除は対象ディスク領域1TiBあたり1GiBのメモリを確保することが推奨されていて、
これはZFSでの重複排除使用時の推奨値と変わらないはずですよ。

重複排除での処理単位のブロックサイズが同じ程度なら、
管理情報のオーバーヘッドはそれほど変わらんでしょう。

**login:Penguin** · 2019/10/01(火) 22:34:34.00

あ、推奨値じゃなくてこれぐらい消費しますよの目安だったかも。

**login:Penguin** · 2019/10/01(火) 23:59:37.95

>>775
メモリ使いすぎないオプションもあるよって書いたんだが...

**login:Penguin** · 2019/10/02(水) 10:24:24.64

NTFSって複雑奇怪な仕様のくせにムダに安定してるよな

**login:Penguin** · 2019/10/02(水) 20:38:07.52

NTFSの重複除去処理って理想的な実装じゃね？

https://www.gmo.jp/report/single/?art_id=234

> 重複除去機能はWindows Server2012ですでに搭載されていましたが、
> 最新のWindows Server 2019の重複除去では、重複除去率とパフォーマンスが改善されており、
> ファイル単位ではなくバイナリのデータ単位で重複を検出して除去するため、
> 大幅に重複除去率が向上しています。

> 重複除去は一度設定すればボリューム内のすべてのファイルが対象となり、定期的に実行されます。
> 書き込みごとに圧縮される場合、継続的なパフォーマンスの懸念がありますが、
> 重複除去はスケジュール設定が可能なため、慢性的なパフォーマンスへの影響を回避することができます。

**login:Penguin** · 2019/10/03(木) 00:59:58.79

NTFSは本当に優秀だ
NT3.1の頃から業務で使っているが、FS起因でのトラブルには一度も遭遇したことがない
さすが天才カトラーが設計しただけある

**login:Penguin** · 2019/10/03(木) 02:03:54.40

MSの開発者のスキルは世界一だからね
本当凄いよ

**login:Penguin** · 2019/10/03(木) 08:52:36.44

優秀つっても Isilon や NetApp とかの後追いじゃないか？
OneFS, WAFL, NTFS 以外は完全において行かれた感がある。
zfs や btrfs はそれなりに資金力ある企業傘下だったが残念だ。

**login:Penguin** · 2019/10/03(木) 08:52:50.20

昔との互換性を重視して、仕様は謎みたいな話もあったけどNTFSは問題ないのか？

**login:Penguin** · 2019/10/03(木) 15:39:46.94

zfsはSunがあんなことにならなければ…

**login:Penguin** · 2019/10/05(土) 20:56:50.83

NTFSの仕様はマジで謎。

**login:Penguin** · 2019/10/22(火) 03:48:30.37

Ubuntu 19.10でZFSをルートファイルシステム利用やっとかよ

**login:Penguin** · 2019/10/22(火) 04:05:31.06

ルートにzfs使うことある？

**login:Penguin** · 2019/10/22(火) 16:37:32.09

zfs重くて泣いた

**login:Penguin** · 2019/10/22(火) 23:17:46.10

zfs raid-1

**login:Penguin** · 2019/10/24(木) 07:14:24.88

ZFSの優秀さはメモリと引き換えなのでパソコンクラスのメモリ量だとあまり使えない

**login:Penguin** · 2019/10/24(木) 14:36:52.38

パソコンクラスってよく分からない表現だな
今のサーバーはほとんどPCサーバーになってきてるのに

**login:Penguin** · 2019/10/24(木) 15:34:41.99

パーソナルなやつだろ

**login:Penguin** · 2019/10/24(木) 19:01:35.46

ZFS出た2005年当時のメモリなんてどれだけだったと思ってるんだ

**login:Penguin** · 2019/10/25(金) 09:09:25.10

うちのパソコンはメモリ512GBだけど足りないかな？

**login:Penguin** · 2019/10/25(金) 09:54:42.46

OpenZFSはメモリ要件が改善されたらしくはあるけど
キャッシュヒットが環境によって変わるとはいえメモリの必要量が明確に分からないのは正直つらい
L2ARCの追加もメモリ消費するらしいから安易にできないし
でもZILとかスナップショットとか透過圧縮とか使いたい

**login:Penguin** · 2019/10/25(金) 10:31:10.97

NASでZFSのdedup onで使ってるけど2TBでメモリ10Gも使わない
メモリ512GB積んでおけば100TBぐらいまでは対応できそうだから個人だとこれで十分そうだ

**login:Penguin** · 2019/10/25(金) 13:35:51.25

重複排除設定で使用済みブロックが2TBも使ってるなら相当ゴツいシステムだな

**login:Penguin** · 2019/10/25(金) 23:24:59.22

重複排除ってサイズが1バイトずれてるだけのやつも
排除してくれるの？

**login:Penguin** · 2019/10/25(金) 23:52:06.19

な訳ねー

**login:Penguin** · 2019/10/25(金) 23:54:37.46

あんまり排除できなくないか？
同じファイル見つけたらハードリンクに
置き換えるツールで十分そうｗ

**login:Penguin** · 2019/10/25(金) 23:57:34.59

そうだよ、専ら仮想鯖みたいな同じユーザランドが無数に作られる様な用途を想定してるんだろう

**login:Penguin** · 2019/10/26(土) 01:22:02.81

一日1万枚ぐらいエロ画像を漁ってると20%ぐらいはかつて落としたエロ画像だったりするから
重複排除は容量の20%ぐらい浮く計算になる

**login:Penguin** · 2019/10/26(土) 01:25:37.95

>>802
そういうのって重複ファイル削除ツール使えばいいだけなんじゃない？
重複させておく必要ないでしょ？

**login:Penguin** · 2019/10/26(土) 01:29:08.15

重複排除はリアルタイムである必要はないわな
ZFSが採用しているようなリアルタイムでの重複排除はメモリを食うし
デスクトップ用途ではデメリットの方が大きい。
XFSの重複排除はパフォーマンスに影響しないし実際に使っているけど便利だよ。

**login:Penguin** · 2019/10/26(土) 02:04:42.61

後で重複を排除するとなると重複かどうかがわからないから結局一度書き込みに行く事になる
zfsはデスクトップ用途だとアレだけどサーバ用途だと理に適ってはいる

あと画像だと今や同じ画像が違うファイル形式であちこちに散乱してたり
同じJPEGでも品質が違ってたりするからあんまし意味ないんじゃ？

**login:Penguin** · 2019/10/26(土) 02:47:15.22

でも書き込むたびに、これ重複してるかな？って
確認してたら、書き込みが遅くなるじゃん

**login:Penguin** · 2019/10/26(土) 06:32:43.54

それを高速化する為にメモリ内にハッシュの類を持ってるんだろうに

**login:Penguin** · 2019/10/26(土) 10:45:29.30

でも書き込むごとに、データのハッシュ値を計算してるんですよね？

**login:Penguin** · 2019/10/26(土) 11:39:20.84

>>807
非同期書き込みなら書き込み遅いのは気にならないが同期書き込みについては
遅くなるのは致命的だよな

同期・非同期で重複排除をバックグラウンドでやるかリアルタイムでやるか決め
られるだろうけど仮想環境用途の仮想ディスクとかはその上の同期・非同期って
NAS側まで伝わるのかね

>>808
ZFSの場合はハッシュの計算以外にもRAIDの計算もしているが、それをいうなら
商用NASハードはそれで百本越えのHDDとか面倒みながら処理してるわけで
ハッシュ計算はそんなに負担ではないのでは？

**login:Penguin** · 2019/10/26(土) 11:54:16.15

いやめちゃくちゃ負担だけど
やらなきゃ駄目だから

**login:Penguin** · 2019/10/27(日) 15:53:27.45

>>800
重複排除はファイル単位ではなくブロック単位
もしファイル単位ならそりゃハードリンクと同じだ

**login:Penguin** · 2019/10/27(日) 17:06:24.41

異なるファイルでブロックが同じってまずないだろ？

**login:Penguin** · 2019/10/27(日) 23:20:14.99

それをファイルレヴェルでやってたらでかいファイルの一部が変更されただけで
ハッシュの類を再度算出しなおさなきゃいけなくなる

**login:Penguin** · 2019/10/28(月) 00:15:16.75

>>812
世代でバックアップとってるファイルとかゲストOSのイメージとか

**login:Penguin** · 2019/10/28(月) 20:47:04.72

ファイル単位の重複排除もあるらしい。
更新されなくなったファイルを圧縮するついでにやる？だったかな。
他にもウイルススキャンとかも定期的に走らせるとかあるからハッシュの
再計算を何かのついでにすることで負担は減らせそうだね。

**login:Penguin** · 2019/10/28(月) 22:31:04.60

>>814
そういうのって仮想マシンソフト側が対応してますよね？

**login:Penguin** · 2019/10/28(月) 23:10:44.32

ファイル単位でやるにしてもどうしても大きさに制限ができる
COWの事を考えるとどうせブロック単位に回帰する

**login:Penguin** · 2019/10/29(火) 00:52:41.78

>>816
横から失礼
同じ仮想マシンイメージのPCを移動ユーザープロファイルで利用する
ならわかるが、サーバだと初期イメージから離れていくだけだから
差分に対しては仮想マシンソフト側での吸収は難しいと思うが

>>817
データベースの表領域を考えるとそうだけど、それ故最近アクセスしていない
ファイルに限定してるんじゃないかな
そうなると話は変わって逆に大きさがわかる/ファイルサイズがわかるのは
寧ろメリットになってしまう

ブロック単位に回帰する理由を挙げるならスナップショットやシンプロ
ビジョニング、ブロック単位のレプリケーションなど併用すると効率的な
機能要件挙げるべきかな

**login:Penguin** · 2019/10/29(火) 03:00:41.08

自宅のCDデータ倉庫で排除率のシミュレーション'(zdb -S)したけど1%も無くてがっかりだった
やっぱZFSの重複排除は仮想化とセットなんかな
バックアップは取得時だけソフトで差分の処理するほうが安くできそうだし

**login:Penguin** · 2019/10/29(火) 08:54:54.57

>>819
zfsは仰る通りだと思う。
コピーオンライトのお陰でスナップショットが高速・少容量な感じに仕上がってる。

**login:Penguin** · 2019/11/16(土) 21:42:02.73

重複排除に夢を見ないほうがいいよ
元から圧縮をはじめとする各方面で無駄を無くす努力がなされている現状で
小手先の策は効果がない

**login:Penguin** · 2019/11/20(水) 20:25:14.01

そうか？今日保存したエロ画像は以前見てHDDのどこかに保存したような気がするんだが

**login:Penguin** · 2019/11/20(水) 20:40:58.51

同じ画像に見えてもバイナリ的に同一じゃない要素があってなぁ
というかそういう画像を探すための同一画像判定をしてくれるアプリがあったな

**login:Penguin** · 2019/11/21(木) 05:47:34.09

画像はまだいいけど同一の動画を判定するのは難しそうだなあ
できるソフトあるのだろうか？

**login:Penguin** · 2019/11/21(木) 09:09:11.59

Googleなら持ってるだろうが

**login:Penguin** · 2019/11/21(木) 09:58:12.19

おれは一期一会派だから

**login:Penguin** · 2019/11/21(木) 20:44:46.78

>>826
年々規制が厳しくなるからいつか後悔するぞ

**login:Penguin** · 2019/11/23(土) 07:34:28.58

すでに御禁制の品です

**login:Penguin** · 2019/11/26(火) 09:21:12.69

>> 826

俺は市毛良枝派だった。

**login:Penguin** · 2019/11/26(火) 19:19:34.18

仮想マシンのイメージのように重複排除が効果的なものはあるけど
そういうのは個別に専用の仕組みで対応したほうが早い
例えば掲示板の画像なら重複を探してハードリンクを貼るスクリプトを定期的に回すだけで事足りる
一応btrfsは重複ブロックを探して共有するプログラムが用意されている

さまざまなリスクと制約を負ってでもリアルタイムにファイルシステムでやる必要性が少ない

**login:Penguin** · 2019/11/26(火) 22:41:02.69

>>830
いやそれだったら画像を保存するだけのプール作ってそこだけdupすればいいだけ

**login:Penguin** · 2019/11/27(水) 01:03:11.01

https://www.phoronix.com/scan.php?page=news_item&;px=Linux-5.4-Released

> Linux 5.4 Kernel Released With exFAT Support, Faster Radeon Graphics, New Hardware

exFATｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

**login:Penguin** · 2019/11/27(水) 01:10:07.14

これでexFATが汎用性最強になったね

**login:Penguin** · 2019/11/27(水) 01:36:26.23

でもジャーナリングファイルシステムじゃないからなぁ

**login:Penguin** · 2019/11/27(水) 01:39:22.97

全く用途が違うだろ・・・
何を見当違いな

**login:Penguin** · 2019/11/27(水) 03:08:57.62

そう言えばRaiserさんはFS開発に戻らないんだろうか

**login:Penguin** · 2019/11/27(水) 07:27:41.14

そもそもSDXCカードの標準に採用されてるのに読み書きできない方がおかしい

**login:Penguin** · 2019/11/27(水) 10:28:42.57

fatは先頭からデータ埋めてくだけだったけどexfatはそのへんどうなの?

**login:Penguin** · 2019/11/29(金) 08:14:02.98

スパースファイルのことなら対応してない
アロケーションのことなら実装次第でFATと変わらんだろう
メタデータの一部がファイル化してるが位置がころころ変わるものじゃないから断片化には影響しない

**login:Penguin** · 2019/12/03(火) 19:17:30.18

Valid Data Length、Linuxで言う所のUnwritten Extentsなら有る
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification#765-validdatalength-field

**login:Penguin** · 2020/01/01(水) 11:10:00.15

https://www.phoronix.com/scan.php?page=news_item&;px=Reiser5-Development

> Reiser5 File-System In Development - Adds Local Volumes With Parallel Scaling Out

> Hans is still serving his fifteen year sentence until 2023 for
> murdering his wife but can see parole eligibility as soon as next month (January 2020).

Hans Reiser仮釈放でReiser5爆誕

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

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