ファイルシステム総合スレ その18
レス数が950を超えています。1000を超えると書き込みができなくなります。
>>849
wikipedia の jfs からだが、
1999年4月、新しい JFS が OS/2 Warp Server for e-business に、2000年10月には OS/2 Warp クライアントに向けてリリースされた。
1999年12月、OS/2 の JFS ソースコードがオープンソースコミュニティに提供され、それを受け JFS の Linux への移植が始まった。2001年6月、JFS for Linux の最初の安定版がリリースされた。 JFSはビデオレコーダーとかのHDDのフォーマットに使われている場合が結構ある/あったか
今はXFSとかか？ >>852
むしろレコーダーにはXFSが使われてるイメージ うちにちょっと古めのRegza(TV)が2台があるが、録画HDDが認識されなくなって
xfs_repairで3回くらい復活させたことがあるわ ZFS厨死亡のお知らせ
ttps://www.phoronix.com/scan.php?page=news_item&px=Linus-Says-No-To-ZFS-Linux じゃあbtrfs使いますかって話よ
俺はトラウマあるから無理 >>855
今までと変えるつもりはないからこれ以上話を出すな、ってだけだと思うんだけど
RedHatがxfsベースで似た機能を持ったもの作るのと、ReiserFSがそこまで取り込んでくれるのを期待 >>856
法的な問題が解決されない関わらないっていうのを改めて明確にしただけだと思うけど ZFSなんかバズワードだって一刀両断は胸がすくね
Macが採用を謳ってからの持ち上げようったらおかしかった linuxではバズワードかもしれないけれど、
FreeBSDなんかは、UFSの代替として一般化してると思うよ。 ソースも見ないアホが語っとるわ
リーナスが言ってるZFSはOracleのZFSのことであってOpenZFSではないぞ xfsが進化しまくってるから問題ない
俺も早速1年くらいxfsのcowで使っているけど
btrfsとは違ってド安定で一切不具合はないよ
ただしメモリの使用量はなんか多い気がする >>863
xfsは昔からメモリ大好きっ子やけんな >>862
ライセンスがGPLにならないかぎりは同じこと >>862
誰にアホといってるのか分からんけど
OpenZFSだろうがライセンスが変わらない限り一緒だといってるだろ たとえGPLになって取り込まれたとしてもZFSに使いどころがないわ
ガリガリ読み書きする部分にはメタデータアクセス遅すぎて使えん
ガチ性能と可用性が必要なところはハードウェアRAID組む
ニアライン用なら機能いらんからもっと安定してるやつ使う LinuxはZFS並みのファイルシステムができるまでまだまだかかりそうね 超サーバ用途には使わんし、かと言って一般的なPCじゃ必要メモリが大き過ぎて使えんし、
運用のハードルが高い割には使いどころが難しいのよね 使ったことないんじゃない？メモリ2GBでも快適だよ
今時のマシンなら16-32G積んでるしちゃんと使ってみてから評価すればいい 2GBで快適に動くような使い方してるならZFSでなくてもいいのではって思うけどな メタデータ触ると遅いしメモリ食いなのは確かだけどlvmでスナップショットはかなり無理矢理感あるし透過圧縮ないファイルシステムも多い snapshot、promote、細かいACL、send|reciveに透過圧縮など非RAIDでも恩恵はでかいよな >>874
だね
俺はデスクトップユーザーだからそれら機能の簡易版でもあればbtrでもxfsでも構わないのだが
現時点では選択肢がzfsしかない うんうんZFSは素晴らしいみたいだからFreeBSDでつかっててね FreeBSDもOpenZFSになるのでLinuxで使いますね 今時は1デバイスで100TB、トータル1PBぐらいのシステムを持っている個人も普通にあるよね
そういうとこで実運用に耐えるファイルシステム、って観点だとこれが以外と難しい 巨大パーティションは下手すればエラーチェックもままならなくなるから
動画用でもない限り1T程度で切ることにしている 重複排除の実装によくハッシュが使われるがハッシュの計算と保存のコストが馬鹿にならない
例えばKSMは最初ハッシュで実装してたのに結局ツリーを作った上で直接比較する方法に変更した NTFSって理論上は64ビットの番地だけど
現在の実装は32ビットなんだろ
(2^32-1)*2048KiBの8PiBくらいしか管理できない そんな容量が要求される様な用途だとReFSが使われるんじゃ？ ファイルシステム上には64ビットで書かれてるよ、
読み書きするときに上位の32ビットを0に固定してるだけ。
たしか、4KBクラスタまでの時代で論理限界16EBとか言ってた。
今は2MBだから増えてる？ まあストレージやメモリのこれだけあれば十分なんて数字は数年で倍になるし10年で2桁変わる 世の中にPBクラスの規模で動いてるファイルシステムって実際にあるのか…？
普通はそんな肥大化する前に設計の見直ししないか 10年前でメモリ80MBとかPentium IIを10年使っていらしたんですか？ 10年前だとメイン機のRAMは8GB、サブ機で2GBだったかな
今はメインで64GBサブ機8GBだから、まあ10倍にはなっていないか
ストレージは1TB→20TB
さらに10年前、2000年時点だとRAM256MBストレージ4GB
1990年頃だとRAM4MBストレージ80MBくらいか
10年で10倍、25年で1000倍目安くらいだな >>888
そこまでいくと実質的に青天井だからS3などのクラウドを選択するだろう
もう自前でストレージを持つ時代じゃない >>888
資源系を筆頭にいくつかの業界や世界規模の大手企業ではPBなんて珍しくないよ
そういうところでは単一ネームスペースでアクセスできるところに意味があるからそうなる
>>891
むしろ逆、そこまで大きくなるとクラウドストレージはI/Oが高すぎて話にならなくなる >>892
事業の性質によるだろう
多くのBtoCビジネスでは、必要なストレージ容量やIOはユーザー数に比例するから問題ない
それで赤字ならそもそも商売として成立しない >>892
PBクラスのシステムのファイルシステムは実際は Lustre や GPFS
などの分散ファイルシステムで、その中身は ext4 などのファイル
システムを並列に並べたものだから、単一のファイルシステムとしては
PB 超えれてない
ここでの議論は単一のファイルシステムに限定したほうがいいと
思うんだがどうだろう >>893
> 事業の性質によるだろう
具体的にはスパコン(HPC)と映像系だけかな
CIFS/NFS(autofs)/オブジェクトストレージあたりは複数のストレージを
束ねて１つのネームスペースに見せかけられるからそこそこ安定してて
こなれた価格のストレージを並べるから PB のファイルシステムは不要
テキトーなこと言うけど、PB クラスのファイルシステムが必要になる
のは１ファイルがTB超えるとか１バッチあたりの中間ファイルがTB超える
とかぐらいからじゃないかな >>894
LustreもGPFSもPanFSも中身は独自でext4等の下層fsを持たないよ、何か別のものと勘違いしてない？ >>895
HPCはそうだけど映像系は実は必ずしも該当しない、ガチなとこは階層化ファイルシステム使うから
日本では技術力がないのか金があるのか知らないけど単一でゴリ押す映像系の話きくけどね
PB越え単一ファイルシステムが必要なのは、一ファイルの大きさが問題じゃなくて
アクセスする可能性があるファイルが大量にあって、かつテープでは遅すぎる場合
だから金融系・資源系・生命系みたいにデータが大量で時間が金に直結するところで良く使われる >>896
おっとすまない、Lustreは下層がext4だった、ごめん勘違いしてたのは俺だった
でもGPFSやPanFSが下層を持たないのは本当
まあ現状エンタープライズのファイルシステムの最前線はGPFS vs PanFSみたいな雰囲気はある >>897
それは失礼。 ちなみに Lustre は ext4 と他に ZFS の実装もあるそうな。
> アクセスする可能性があるファイルが大量にあって、かつテープでは遅すぎる場合
使ってる業種と使い方に異論はないんだけど単一ファイルシステムを使う理由が
それかというとちょっとなんか釈然としないなぁ
結局入力ファイルや中間ファイルを複数のファイルサーバに負荷分散するように組むのが
面倒くさいから使ってるってだけって印象だわ
面倒くさがらなった結果の一つが Hadoop/HDFS だと思ってます、ハイ 1ファイル1'PBのエロ動画とかどうやって保存してるんだろう >>900
Display Portが2.7Gb/s最大なんで少なく見積もっても823時間分あるんだが
どういう人向けなのか説明Plz >>901
DPは最大25Gbps出るしDSC使えばもっといける
そもそもファイルサイズとモニターへの転送速度は関係ないでしょ？
実際に販売する段階になったらエンコードして小さくするとしても編集前のマスターデータをそのまま保存しておく場合なら再生するモニター以上の解像度、フレームレート、色域が記録されていても保存に必要な容量が用意できれば全く問題ない 8K24bitの24時間ハメ撮りAVだと無圧縮で計算上約8TBだな RAID10はmd raidよりbtrfsのほうが安定してる
RAID 1ならmdのほうがいいけど >>907,908
md の上に何乗せてるん? ext4? xfs? >>909
RAID1なら何でも乗っける
ESPの多重化もしたいし
それ以外ならファイルシステムのネイティブ機能の方がいいと思う 2020年2月10日 Linus，次期カーネル「Linux 5.6」の最初のリリース候補版を公開
https://gihyo.jp/admin/clip/01/linux_dt/202002/10
ここで触れられているZonefsは開発したWDによるとSMR HDDやSSDに適したファイルシステムらしい
What is Zoned Storage and the Zoned Storage Initiative?
https://blog.westerndigital.com/what-is-zoned-storage-initiative/ ZonefsはPOSIXに準拠していないので既存のファイルシステムを置き換えるものじゃないけどな F2FSは最大FSサイズが16TBなのがSMR HDDには今後ネックになる FlashFriendly File Systemだからな
HDDとか知らんよ HDDも大容量キャッシュ付き瓦だとあんまりfs側でいじらない方がいいような気がする WinFS でやりたかったDB の機能も付いたファイルシステムってあります？ >>920
じゃあそれDBでよくね？ってなってどこも開発やめた 最近はDBのためにダイレクトIOのパフォーマンス上げる改善が多い btrfsはUUIDの変更が鬼門だな
メタデータとUUIDが紐付いているらしくてデータを読めなくなる カーネル5.4で追加されたネイティブexFATは日付の処理にバグ有り
Windows7とfuse-exFATで作成したファイルを5.4のネイティブexFATドライバで見ると、
更新日付がちょうど 1ヶ月＋9時間 遅く表示される
アクセス日付は常に 1979/12/31 9:00:00 と表示される
5.4のネイティブexFATドライバで作成したファイルをWindows7で見ると、
更新日付とアクセス日付がちょうど 9時間 早く表示される
また、5.4のネイティブexFATドライバでマウントしなおすと上記の症状が起こる
つまり、
・読み書き共にタイムロケールが正しく反映されない (日本設定では9時間ずれる)
・読み込みのみ暦月がずれて読み込まれる (書き込み直後はキャッシュされるので症状が見えない) あと、5.4のネイティブexFATは日本語処理は問題なかった
日付のずれは地味に困るから一旦fuse-exFATに戻す アクセス日付を更新するだけでも更新日付が一ヶ月後ろにずれることも分かった
サムネイル表示機能を有効にしてたから試しに開いたSDカードの日付情報も派手にやられた Windows10
5000個以上のPDFをAドライブからBドライブに移動させたら、ファイル数はそのまんまなのに総サイズが250MBも減少した
なんで？ A側はexfat でアロケーションユニットサイズが 1MB (平均512KB/ファイル余計に消費)で、
B側はNTFSで同サイズが4KBで(同平均2KB/ファイル)だったって感じか？
(意図的にやらない限り 1MB なんて値にはならないはず)
それ以外の可能性としてはA側には隠しファイルがあってサイズは隠しファイル込みだった exFatをWindowsで初期設定でフォーマットするとクラスタサイズが128KiBになる
1ファイルあたり平均64KiB余計に消費するので、64KiB×5000個=約312MiB
>>929 は順当な結果 1件1ファイルで保存するタイプのメールデータをexFatに保存すると大変なことになる
(1件ごとにほぼ128KiB無駄になる)
あとNTFSは約700バイト未満のファイルはメタデータに直接格納しちゃうから細かい設定ファイルやらメールデータの収納効率が非常に良い Ubuntu 20.04β試していて初めて知ったんだけどlinux-5.3あたり（？）からNILFS2へ書き込もうとするとクラッシュする（といってもNIFS2を扱っているカーネルのサブシステムだけ）というトラップ（バグ）が仕掛けられてたのね。
/homeをNILFS2で運用していて18.04でバックポートカーネルを入れるとログインできなくなるんで何でだろうと思っていた。
当分18.04+5.0系カーネルで保持かなあ？ NILFS2って保守されてるのか？
いつか消されるんじゃないかと思っているのだけど 4TB の外付けHDDを exFAT でアロケーションユニットサイズを NTFS と同じ 4kB で使う場合、
大きなデメリットってある？
それとも、アロケーションユニットサイズを変更するくらいなら、素直に NTFS で使ったほうがいい？
Linux でもネイティブ対応しそうな exFAT を考慮したいけど、
今までの外付けHDDが全部 NTFS なので、
ちょっと躊躇してしまう。 数十〜数百GB程度ならexFATでも何でも構わんけど
テラバイトサイズのボリュームはジャーナリングファイルシステムでないと怖すぎないか >>938
確かに、ジャーナルのない点は少し気になるねぇ。
サルベージするときの復元率の違いも気になる。
FAT32 のときは、復元できても断片になることもあった。
もっとも、NTFS の場合、復元できなければ断片すら拾えないという感じだから、
優劣という感じじゃないしなぁ。 >>937
そのFSを読めるOSが壊れたときなんて想定は別の同じOSを用意すればいいでしかないぞ >>937
Windows95/98と同じ程度の信頼性はあるはず CoWはその性質上、空き領域をどんどん上書きするからSSDの速度低下が起きやすいようだ
定期的にトリムした方が良い、例えば毎朝と毎夕
マウントオプションでdiscardオプションを付けても良いがLinuxでは遅くなることが多い
fstrim -v / >>935
NILFS2開発者のMLにとりあえずの回避策が流れてた。
起動からマウントまでの間にそのFSのデバイスへの書き込みがあればいいので、
マウントの前に
dd if=/dev/なんとか of=/dev/なんとか count=1
みたいにダミーの書き込みを発生さればいいのだそう。
例えば、fstabから削除かnoautoにしてrc.localとかでdd, mountという流れとか。 >>946
ありがとう。
たぶんこれかな↓
https://marc.info/?l=linux-kernel&;m=158825033005228&w=2
自分の場合も/homeがnilfs2なんでどうしたものかな？？？というところですわ。
サブ機のほうはbtrfsに替えてUbuntu20.04に上げたけどメイン機の方はどうするかなあ？ Btrfsとかzfsって一台のhddだけで運用するのはたいしてメリットないの？ あるだろ
圧縮とかスナックショトとか 盛りだくさんだわ
>>948 デュアルブートしてたらNTFSのMFTがミラー毎壊れたんですけどなんとかMFTを修復できませんかね？
EaseUS Data Recovery Wizardを使うとディレクトリやファイル名がそのままでデータ救出できるんですけど
という事はMFTも修復できるはずですよね？ レス数が950を超えています。1000を超えると書き込みができなくなります。
