20/01/14 17:38:02.82 3ySwGeCo.net
>>862
誰にアホといってるのか分からんけど
OpenZFSだろうがライセンスが変わらない限り一緒だといってるだろ
887:login:Penguin
20/01/21 20:00:20.75 ugNUCPRp.net
たとえGPLになって取り込まれたとしてもZFSに使いどころがないわ
ガリガリ読み書きする部分にはメタデータアクセス遅すぎて使えん
ガチ性能と可用性が必要なところはハードウェアRAID組む
ニアライン用なら機能いらんからもっと安定してるやつ使う
888:915
20/01/21 22:45:23 iC7ldWE7.net
LinuxはZFS並みのファイルシステムができるまでまだまだかかりそうね
889:login:Penguin
20/01/22 00:52:27.43 RmlHZiYt.net
超サーバ用途には使わんし、かと言って一般的なPCじゃ必要メモリが大き過ぎて使えんし、
運用のハードルが高い割には使いどころが難しいのよね
890:915
20/01/22 00:59:56.25 97fPzXLY.net
使ったことないんじゃない？メモリ2GBでも快適だよ
今時のマシンなら16-32G積んでるしちゃんと使ってみてから評価すればいい
891:login:Penguin
20/01/22 01:20:43 sJWFkN+Y.net
2GBで快適に動くような使い方してるならZFSでなくてもいいのではって思うけどな
892:login:Penguin
20/01/22 01:58:33 wZeNZHAR.net
メタデータ触ると遅いしメモリ食いなのは確かだけどlvmでスナップショットはかなり無理矢理感あるし透過圧縮ないファイルシステムも多い
893:login:Penguin
20/01/22 07:16:30 97fPzXLY.net
snapshot、promote、細かいACL、send|reciveに透過圧縮など非RAIDでも恩恵はでかいよな
894:login:Penguin
20/01/22 11:38:59 sjf0Rz/o.net
>>874
だね
俺はデスクトップユーザーだからそれら機能の簡易版でもあればbtrでもxfsでも構わないのだが
現時点では選択肢がzfsしかない
895:login:Penguin
20/01/22 16:00:37 vGgGBPjr.net
うんうんZFSは素晴らしいみたいだからFreeBSDでつかっててね
896:login:Penguin
20/01/23 01:55:54.94 7qSP8O0Q.net
FreeBSDもOpenZFSになるのでLinuxで使いますね
897:login:Penguin
20/01/23 14:10:17.07 ZAgXInmL.net
有料でも良ければGPFSが最強なんだけどねえ
898:login:Penguin
20/01/23 14:14:08.14 ZAgXInmL.net
今時は1デバイスで100TB、トータル1PBぐらいのシステムを持っている個人も普通にあるよね
そういうとこで実運用に耐えるファイルシステム、って観点だとこれが以外と難しい
899:login:Penguin
20/01/23 23:53:42.57 6UDxr1tc.net
NTFS
900:login:Penguin
20/01/24 18:35:07 mXgeSarq.net
巨大パーティションは下手すればエラーチェックもままならなくなるから
動画用でもない限り1T程度で切ることにしている
901:login:Penguin
20/01/25 04:40:01 hgworRLd.net
重複排除の実装によくハッシュが使われるがハッシュの計算と保存のコストが馬鹿にならない
例えばKSMは最初ハッシュで実装してたのに結局ツリーを作った上で直接比較する方法に変更した
902:login:Penguin
20/01/25 06:07:36 v2Q4em8k.net
NTFSって理論上は64ビットの番地だけど
現在の実装は32ビットなんだろ
(2^32-1)*2048KiBの8PiBくらいしか管理できない
903:login:Penguin
20/01/25 06:30:47 RUYaEyw5.net
そんな容量が要求される様な用途だとReFSが使われるんじゃ？
904:login:Penguin
20/01/25 07:53:48 TTbJFqbp.net
ファイルシステム上には64ビットで書かれてるよ、
読み書きするときに上位の32ビットを0に固定してるだけ。
たしか、4KBクラスタまでの時代で論理限界16EBとか言ってた。
今は2MBだから増えてる？
905:login:Penguin
20/01/25 10:14:39 9dDjJPoq.net
個人だとだいたい100TBもあれば足りるからな
906:login:Penguin
20/01/25 13:29:15 FQlZOJvl.net
まあストレージやメモリのこれだけあれば十分なんて数字は数年で倍になるし10年で2桁変わる
907:login:Penguin
20/01/25 15:54:16.50
908:Pn3gpz30.net
909:login:Penguin
20/01/25 16:15:25.18 XUbXy/+j.net
10年前でメモリ80MBとかPentium IIを10年使っていらしたんですか？
910:login:Penguin
20/01/25 17:43:01 FQlZOJvl.net
10年前だとメイン機のRAMは8GB、サブ機で2GBだったかな
今はメインで64GBサブ機8GBだから、まあ10倍にはなっていないか
ストレージは1TB→20TB
さらに10年前、2000年時点だとRAM256MBストレージ4GB
1990年頃だとRAM4MBストレージ80MBくらいか
10年で10倍、25年で1000倍目安くらいだな
911:login:Penguin
20/01/25 20:54:00 9YpFJvCS.net
>>888
そこまでいくと実質的に青天井だからS3などのクラウドを選択するだろう
もう自前でストレージを持つ時代じゃない
912:login:Penguin
20/01/26 10:26:40 AHO9IC4m.net
>>888
資源系を筆頭にいくつかの業界や世界規模の大手企業ではPBなんて珍しくないよ
そういうところでは単一ネームスペースでアクセスできるところに意味があるからそうなる
>>891
むしろ逆、そこまで大きくなるとクラウドストレージはI/Oが高すぎて話にならなくなる
913:login:Penguin
20/01/26 11:00:01 OzJ+Z2xw.net
>>892
事業の性質によるだろう
多くのBtoCビジネスでは、必要なストレージ容量やIOはユーザー数に比例するから問題ない
それで赤字ならそもそも商売として成立しない
914:login:Penguin
20/01/26 11:21:19 kSy9PDTE.net
>>892
PBクラスのシステムのファイルシステムは実際は Lustre や GPFS
などの分散ファイルシステムで、その中身は ext4 などのファイル
システムを並列に並べたものだから、単一のファイルシステムとしては
PB 超えれてない
ここでの議論は単一のファイルシステムに限定したほうがいいと
思うんだがどうだろう
915:login:Penguin
20/01/26 11:44:24 kSy9PDTE.net
>>893
> 事業の性質によるだろう
具体的にはスパコン(HPC)と映像系だけかな
CIFS/NFS(autofs)/オブジェクトストレージあたりは複数のストレージを
束ねて１つのネームスペースに見せかけられるからそこそこ安定してて
こなれた価格のストレージを並べるから PB のファイルシステムは不要
テキトーなこと言うけど、PB クラスのファイルシステムが必要になる
のは１ファイルがTB超えるとか１バッチあたりの中間ファイルがTB超える
とかぐらいからじゃないかな
916:login:Penguin
20/01/26 11:53:39 AHO9IC4m.net
>>894
LustreもGPFSもPanFSも中身は独自でext4等の下層fsを持たないよ、何か別のものと勘違いしてない？
917:login:Penguin
20/01/26 12:22:35 AHO9IC4m.net
>>895
HPCはそうだけど映像系は実は必ずしも該当しない、ガチなとこは階層化ファイルシステム使うから
日本では技術力がないのか金があるのか知らないけど単一でゴリ押す映像系の話きくけどね
PB越え単一ファイルシステムが必要なのは、一ファイルの大きさが問題じゃなくて
アクセスする可能性があるファイルが大量にあって、かつテープでは遅すぎる場合
だから金融系・資源系・生命系みたいにデータが大量で時間が金に直結するところで良く使われる
918:login:Penguin
20/01/26 12:26:01 AHO9IC4m.net
>>896
おっとすまない、Lustreは下層がext4だった、ごめん勘違いしてたのは俺だった
でもGPFSやPanFSが下層を持たないのは本当
まあ現状エンタープライズのファイルシステムの最前線はGPFS vs PanFSみたいな雰囲気はある
919:login:Penguin
20/01/26 13:52:42.43 kSy9PDTE.net
>>897
それは失礼。 ちなみに Lustre は ext4 と他に ZFS の実装もあるそうな。
> アクセスする可能性があるファイルが大量にあって、かつテープでは遅すぎる場合
使ってる業種と使い方に異論はないんだけど単一ファイルシステムを使う理由が
920: それかというとちょっとなんか釈然としないなぁ 結局入力ファイルや中間ファイルを複数のファイルサーバに負荷分散するように組むのが 面倒くさいから使ってるってだけって印象だわ 面倒くさがらなった結果の一つが Hadoop/HDFS だと思ってます、ハイ
921:login:Penguin
20/01/26 14:09:39.49 aLHVJ+JL.net
1ファイル1'PBのエロ動画とかどうやって保存してるんだろう
922:login:Penguin
20/01/27 01:02:02 SjNVe4Yy.net
>>900
Display Portが2.7Gb/s最大なんで少なく見積もっても823時間分あるんだが
どういう人向けなのか説明Plz
923:login:Penguin
20/01/27 12:29:14 0w7PQcpt.net
>>901
DPは最大25Gbps出るしDSC使えばもっといける
そもそもファイルサイズとモニターへの転送速度は関係ないでしょ？
実際に販売する段階になったらエンコードして小さくするとしても編集前のマスターデータをそのまま保存しておく場合なら再生するモニター以上の解像度、フレームレート、色域が記録されていても保存に必要な容量が用意できれば全く問題ない
924:login:Penguin
20/01/27 14:05:19 vU+1ytkI.net
>>886
得ろ動画溜め込むのに少ない
925:login:Penguin
20/01/27 18:07:52 udH3RDqL.net
8K24bitの24時間ハメ撮りAVだと無圧縮で計算上約8TBだな
926:login:Penguin
20/02/02 12:09:33 Hg2ze+cG.net
>>836,841,843
この流れ好き
927:login:Penguin
20/02/02 15:16:02 GHB58PtI.net
Linuxのファイルシステム「Btrfs」を5年間使用した記録
URLﾘﾝｸ(gigazine.net)
928:login:Penguin
20/02/02 15:26:44.86 U7jFn1mT.net
RAIDはmd使った方が無難に思える
929:login:Penguin
20/02/02 17:40:25 HE+GXCHP.net
RAID10はmd raidよりbtrfsのほうが安定してる
RAID 1ならmdのほうがいいけど
930:login:Penguin
20/02/02 23:14:15.47 cDfryaOr.net
>>907,908
md の上に何乗せてるん? ext4? xfs?
931:login:Penguin
20/02/02 23:40:34.80 iaNiREzj.net
スーパー32Xに決まっておる
932:login:Penguin
20/02/03 05:01:47.23 9XLDxuL9.net
>>909
RAID1なら何でも乗っける
ESPの多重化もしたいし
それ以外ならファイルシステムのネイティブ機能の方がいいと思う
933:login:Penguin
20/02/03 11:50:13 1h1DB/oS.net
>>910
その発想はなかった。俺は評価する。
934:login:Penguin
20/02/03 23:45:36 OVT3+6Po.net
セガファンは面白いやつ多いのにセガはあれだな
935:login:Penguin
20/02/11 01:11:17 gTMJQSdw.net
2020年2月10日 Linus，次期カーネル「Linux 5.6」の最初のリリース候補版を公開
URLﾘﾝｸ(gihyo.jp)
ここで触れられているZonefsは開発したWDによるとSMR HDDやSSDに適したファイルシステムらしい
What is Zoned Storage and the Zoned Storage Initiative?
URLﾘﾝｸ(blog.westerndigital.com)
936:login:Penguin
20/02/11 10:00:56.86 JmaZPai6.net
ZonefsはPOSIXに準拠していないので既存のファイルシステムを置き換えるものじゃないけどな
937:login:Penguin
20/02/11 22:35:10 F8Fgy0xz.net
f2fsじゃあかんのかね
938:login:Penguin
20/02/15 20:40:39 ko2/1+4j.net
F2FSは最大FSサイズが16TBなのがSMR HDDには今後ネックになる
939:login:Penguin
20/02/15 20:51:22 fQlV7izm.net
FlashFriendly File Systemだからな
HDDとか知らんよ
940:login:Penguin
20/02/15 21:41:41 7ROaKxuF.net
HDDも大容量キャッシュ付き瓦だとあんまりfs側でいじらない方がいいような気がする
941:login:Penguin
20/02/15 23:17:25 Aj0iDWta.net
WinFS でやりたかったDB の機能も付いたファイルシステムってあります？
942:login:Penguin
20/02/16 09:36:26.82 tFc9/bu5.net
>>920
じゃあそれDBでよくね？ってなってどこも開発やめた
943:login:Penguin
20/02/16 11:11:50 Cl0cNLYW.net
最近はDBのためにダイレクトIOのパフォーマンス上げる改善が多い
944:login:Penguin
20/02/19 08:46:06 +vuP13XZ.net
Googleが新しいファイルシステム作ってる
Android用だからLinuxのメインラインに取り込まれるのか分からんけど
ダウンロード中の不完全なファイルでも実行できるらしい
URLﾘﾝｸ(lore.kernel.org)
945:login:Penguin
20/03/20 16:46:34 oDz6Qr3S.net
btrfsはUUIDの変更が鬼門だな
メタデータとUUIDが紐付いているらしくてデータを読めなくなる
946:login:Penguin
20/03/29 17:30:13 ZSfzV/DF.net
btrfs使わなええ
947:login:Penguin
20/03/29 19:29:33.05 A9QWVCnu.net
カーネル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時間ずれる)
・読み込みのみ暦月がずれて読み込まれる (書き込み直後はキャッシュされるので症状が見えない)
948:login:Penguin
20/03/29 19:38:05.23 A9QWVCnu.net
あと、5.4のネイティブexFATは日本語処理は問題なかった
日付のずれは地味に困るから一旦fuse-exFATに戻す
949:926
20/03/29 20:21:00.98 A9QWVCnu.net
アクセス日付を更新するだけでも更新日付が一ヶ月後ろにずれることも分かった
サムネイル表示機能を有効にしてたから試しに開いたSDカードの日付情報も派手にやられた
950:login:Penguin
20/04/08 08:54:17.25 ctV6ZAP7.net
Windows10
5000個以上のPDFをAドライブからBドライブに移動させたら、ファイル数はそのまんまなのに総サイズが250MBも減少した
なんで？
951:login:Penguin
20/04/08 09:48:50 h2p5sSpc.net
圧縮ディスクだった
952:login:Penguin
20/04/08 16:48:38 nNfYJP3N.net
Aドライブってフロッピー？
953:login:Penguin
20/04/08 18:26:58 9nhczXSy.net
A側はexfat でアロケーションユニットサイズが 1MB (平均512KB/ファイル余計に消費)で、
B側はNTFSで同サイズが4KBで(同平均2KB/ファイル)だったって感じか？
(意図的にやらない限り 1MB なんて値にはならないはず)
それ以外の可能性としてはA側には隠しファイルがあってサイズは隠しファイル込みだった
954:login:Penguin
20/04/09 01:04:11 NYHCWS9d.net
exFatをWindowsで初期設定でフォーマットするとクラスタサイズが128KiBになる
1ファイルあたり平均64KiB余計に消費するので、64KiB×5000個=約312MiB
>>929 は順当な結果
955:login:Penguin
20/04/09 01:09:19.65 NYHCWS9d.net
1件1ファイルで保存するタイプのメールデータをexFatに保存すると大変なことになる
(1件ごとにほぼ128KiB無駄になる)
あとNTFSは約700バイト未満のファイルはメタデータに直接格納しちゃうから細かい設定ファイルやらメールデータの収納効率が非常に良い
956:login:Penguin
20/04/09 08:50:59.38 tHpWeU4o.net
Ubuntu 20.04β試していて初めて知ったんだけどlinux-5.3あたり（？）からNILFS2へ書き込もうとするとクラッシュする（といってもNIFS2を扱っているカーネルのサブシステムだけ）というトラップ（バグ）が仕掛けられてたのね。
/homeをNILFS2で運用していて18.04でバックポートカーネルを入れるとログインできなくなるんで何でだろうと思っていた。
当分18.04+5.0系カーネルで保持かなあ？
957:login:Penguin
20/04/09 10:29:58.44 wTSYL5PJ.net
NILFS2って保守されてるのか？
いつか消されるんじゃないかと思っているのだけど
958:login:Penguin
20/04/09 12:30:14.75 7wAsdCRN.net
4TB の外付けHDDを exFAT でアロケーションユニットサイズを NTFS と同じ 4kB で使う場合、
大きなデメリットってある？
それとも、アロケーションユニットサイズを変更するくらいなら、素直に NTFS で使ったほうがいい？
Linux でもネイティブ対応しそうな exFAT を考慮したいけど、
今までの外付けHDDが全部 NTFS なので、
ちょっと躊躇してしまう。
959:login:Penguin
20/04/09 12:47:50.43 f9lVta1Z.net
数十～数百GB程度ならexFATでも何でも構わんけど
テラバイトサイズのボリュームはジャーナリングファイルシステムでないと怖すぎないか
960:937
20/04/09 13:13:20 7wAsdCRN.net
>>938
確かに、ジャーナルのない点は少し気になるねぇ。
サルベージするときの復元率の違いも気になる。
FAT32 のときは、復元できても断片になることもあった。
もっとも、NTFS の場合、復元できなければ断片すら拾えないという感じだから、
優劣という感じじゃないしなぁ。
961:login:Penguin
20/04/09 17:40:41 vpGccY6F.net
>>936
ジャップ製モジュールはこれが怖い
962:login:Penguin
20/04/09 18:04:57.35 9fEj1NQk.net
チョン？
963:login:Penguin
20/04/09 22:32:27 4pQr46JD.net
手伝お？
964:login:Penguin
20/04/10 16:47:03 mZNoA7ar.net
>>937
そのFSを読めるOSが壊れたときなんて想定は別の同じOSを用意すればいいでしかないぞ
965:login:Penguin
20/04/11 22:41:34.77 XDts1cPd.net
>>937
Windows95/98と同じ程度の信頼性はあるはず
966:login:Penguin
20/04/24 00:01:20.91 OEQFvFGC.net
CoWはその性質上、空き領域をどんどん上書きするからSSDの速度低下が起きやすいようだ
定期的にトリムした方が良い、例えば毎朝と毎夕
マウントオプションでdiscardオプションを付けても良いがLinuxでは遅くなることが多い
fstrim -v /
967:login:Penguin
20/05/03 18:58:52 njMyCBBl.net
>>935
NILFS2開発者のMLにとりあえずの回避策が流れてた。
起動からマウントまでの間にそのFSのデバイスへの書き込みがあればいいので、
マウントの前に
dd if=/dev/なんとか of=/dev/なんとか count=1
みたいにダミーの書き込みを発生さればいいのだそう。
例えば、fstabから削除かnoautoにしてrc.localとかでdd, mountという流れとか。
968:login:Penguin
20/05/05 05:14:55 AUhfSTN7.net
>>946
ありがとう。
たぶんこれかな↓
URLﾘﾝｸ(marc.info)
自分の場合も/homeがnilfs2なんでどうしたものかな？？？というところですわ。
サブ機のほうはbtrfsに替えてUbuntu20.04に上げたけどメイン機の方はどうするかなあ？
969:login:Penguin
20/05/26 11:43:00 1H93WhIH.net
Btrfsとかzfsって一台のhddだけで運用するのはたいしてメリットないの？
970:login:Penguin
20/05/26 12:46:01.35 +ELcO//y.net
あるだろ
圧縮とかスナックショトとか 盛りだくさんだわ
>>948
971:login:Penguin
20/05/26 17:16:39.31 o4/8jJLs.net
デュアルブートしてたらNTFSのMFTがミラー毎壊れたんですけどなんとかMFTを修復できませんかね？
EaseUS Data Recovery Wizardを使うとディレクトリやファイル名がそのままでデータ救出できるんですけど
という事はMFTも修復できるはずですよね？
972:login:Penguin
20/05/26 22:43:28.04 6YtvPgat.net
Btrfsの将来は
973:login:Penguin
20/05/27 08:05:49.48 uLCM26Hl.net
君の頑張り次第
974:login:Penguin
20/05/27 12:56:13.77 XCSTzVNb.net
まだ始まったばかりだ！
Oracke先生の次回作にご期待ください
975:login:Penguin
20/05/27 20:57:11.66 acGll7c1.net
xfsのCoWを有効化したまま1年以上使ったけど時々フリーズするなやっぱり
あとメモリ使用量がちょっと大きすぎるね。
まだまだext4安定の時代は続きそうだ
976:login:Penguin
20/05/27 21:38:26 0U4TUkPK.net
それならBtrfsの方が安定してるな。できたばかりでこれからなんだろうけど
977:login:Penguin
20/05/27 21:42:16 wyekam7t.net
2017年8月3日 Red Hat，RHEL 7.4リリースで"脱Btrfs"を明らかに
URLﾘﾝｸ(gihyo.jp)
978:login:Penguin
20/05/27 22:26:06 sT3KZO5+.net
ext5開発開始まだー
979:login:Penguin
20/05/28 05:14:42.87 6u6TfIVC.net
うーむbtrfsで組んでる領域どうしよう
compress標準サポートが貴重なんだけどな。
乗り換え先おすすめ教えてください。
980:login:Penguin
20/05/28 09:40:13.16 lg5ytPVY.net
なんでBtrfsなんか選択したんや…
981:login:Penguin
20/05/28 09:46:17.62 bvSCyOR7.net
Synologyが推してるBtrfs
Googleが使ってるBtrfs
982:login:Penguin
20/05/28 09:54:45.61 EreFZKCr.net
btrfsはヤヴァいと何度言えば（ｒｙ
983:login:Penguin
20/05/28 10:35:33.75 kpVDAvmO.net
>>958
zfs
984:login:Penguin
20/05/28 11:26:26.96 ztRPopnD.net
なんだかんだでLinuxで高機能モダンファイルシステム使おうと思うととりあえず何も考えずに使えるのがBtrfsなんだよね。
こまめにバックアップ取りながら人柱のつもりで突っ込んだのに、意外と問題出ないし……
985:login:Penguin
20/05/28 12:31:52 A6PA4iBR.net
Google遣ってるならBtrfsの未来は明るいと思ってしまう不思議
986:login:Penguin
20/05/28 12:36:38 rCbDOGHF.net
>>963
俺も数年使ってるけど何も問題起きてないわ
ぼんやり使ってるだけだから気付いてないだけの可能性もあるけど
987:login:Penguin
20/05/28 14:51:58.35 kpVDAvmO.net
ぐぐたすヲもう忘れたのか?
988:login:Penguin
20/05/28 16:25:14 qJC8ExER.net
IT巨人で信頼できるのはMSだけだわ
Window以外はブッチギリで有能
989:login:Penguin
20/05/28 22:47:31.09 35G/ZT7g.net
Vista以降のWindowsもNTFSも優秀だよ
今時こんな堅牢なOSちょっと無いよ
990:login:Penguin
20/05/29 01:50:04.11 /sA5f8CX.net
URLﾘﾝｸ(wiki.archlinux.jp)
本当に隅から隅まで問題が起きていないのか、問題が起きた時にfsckの類が動くのか、etc
よくbtrfsなんぞ使えるな・・・
991:login:Penguin
20/05/29 05:52:56.10 BCgb8iXY.net
そんなこと言ったらext4もxfsも使えんぞ
992:login:Penguin
20/05/30 22:19:12.00 rxDacgPJ.net
ext4もxfsもBtrfs程の問題は抱えてないだろうて
Btrfsは解決の目途が立ってない既知の問題点が多すぎる
993:login:Penguin
20/05/31 00:36:23.90 O/t7Lowh.net
具体的に何が既知の問題なんだ？
994:login:Penguin
20/05/31 00:46:30.60 4i1+bTSg.net
何故>>969すら見ないのか・・・
995:login:Penguin
20/05/31 00:56:48.74 O/t7Lowh.net
>>973
そこ見たら実験的な機能が多いのは分かるけど
普通に使って問題が起きるようなことは書いていないが
996:login:Penguin
20/05/31 01:04:37 4i1+bTSg.net
マウントオプションを貪らずに一切エラーが起きなきゃな
起きた時が問題だからbtrfs checkで全部を直せないとかマウントオプション云々だとか散々警告されてんだろうに
RedHatが匙を投げたって時点でお察し
997:login:Penguin
20/06/01 15:44:25 RZhBr4iC.net
Googleってbtrfs使ってんの？
998:login:Penguin
20/06/01 18:14:25 7+mv9XDP.net
redhat引き合いに出してbtrfsオワコン唱えるやつ多いけどbtrfs開発者がredhatやめたってだけ
んでまともに触れる社員いないfsはサポート無理ってのとチーム内にXFS開発者ならいっぱいいるからだって元社員がいってたぞ
googleは知らんが大御所で使ってる、貢献してるのはfacebookと富士通とかだな
999:login:Penguin
20/06/01 18:38:32.80 uT4k0Fz5.net
GoogleはChromeOS内のLinux環境で使ってるだけ
1000:login:Penguin
20/06/01 18:40:48.93 2PrO6u28.net
>>978
それってけっこうデカくね？
1001:login:Penguin
20/06/01 19:50:25 OAVwE/lA.net
遭遇してもクリーンインスコすりゃいいって程度のシステムならbtrfsでも問題にならんのだろうけどな
redhatの件が無くてもbtrfsは昔からモグラ叩きの繰り返しだし、
未だにRAIDやファイルチェック周辺すら完全にできてないし、どこに地雷があるかわからん
一部のfsのエラーを修復できませんって、そのエラーに遭遇した時にどうすんだよと
1002:login:Penguin
20/06/01 21:36:44.83 9JaREmBh.net
クライアント(スナップショット/RAIDなし)で使えててもファイルサーバで
安心して使えるかというとそうじゃないからなあ
1003:login:Penguin
20/06/01 21:56:25.70 2PrO6u28.net
スナップショットもRAIDも使ったし、オンラインでストレージ構成変えまくったけど問題出なくて（しかも構成変更が柔軟過ぎて）拍子抜けしたんだよなぁ。
ファイルサーバ用途でこそ輝くよこれ（バックアップはこまめにね）
1004:login:Penguin
20/06/02 11:47:13 6oGgMjKL.net
ファイルサーバーっていう言葉で考えているものが全然違う二人で会話してる感じがする
1005:login:Penguin
20/06/02 12:27:10 sg8jbCA1.net
Terastation クラスの NAS(Btrfs 利用だと Synology の製品)/エントリークラスか
会社のファイルサーバ(Isilon や NetApp やその対抗製品クラス)/
エンタープライズクラスかってことかな
クラウド化やセキュリティ強化が進むにつれてエントリークラスの需要は
落ちる/落ちてるんじゃないかな
1006:login:Penguin
20/06/04 01:47:45 xNtEdgfL.net
ノートPCをCoW有効にしたXfsにしてるけど
メモリ使いすぎて本気で後悔してる。
省メモリなFSだとext4が良いのかな？
どこかにFSごとのメモリ使用量の比較データとかあたりしない？
1007:login:Penguin
20/06/04 07:54:18.56 gBysGF/t.net
そんなにメモリ食うの？
1008:login:Penguin
20/06/04 09:23:07.24 Bs6FKlOi.net
信じられないくらい食う
プロセスの合計メモリ使用量は大したことないのに
簡単にスワップ突入するよ。
1009:login:Penguin
20/06/04 09:40:20.48 DMZuMarq.net
CoWとジャーナリングなら比べるのも愚かというレベル
1010:login:Penguin
20/06/04 09:51:37.00 Bs6FKlOi.net
というかカーネル4.18からDefaultでreflink有効になったのかよ・・・
URLﾘﾝｸ(blogs.oracle.com)
もはやxfsは別物じゃん
1011:login:Penguin
20/06/04 11:31:13.32 DQZXMKEK.net
>>985
使ってないけどメモリ制限できるんでは？
1012:login:Penguin
20/06/04 12:01:52.27 gBysGF/t.net
dedup使ってるとかでもなしにそんなメモリ食うのか。
Btrfsがメモリ食わないからCoW自体は対してメモリ食わないものだと思ってた
1013:login:Penguin
20/06/04 15:07:25.35 x4v3XzWR.net
CoWを無効にしたXFS使って比較しろよ
1014:login:Penguin
20/06/04 17:36:35.28 7r9XEAZX.net
>>946
これはGood News?
>> Wondering if it can be reproduced on mainline with c3aab9a0bd91
>> ("mm/filemap.c: dont initiate writeback if mapping has no dirty pages")
>> reverted?
>
> For mainline kernels with that commit reverted, this oops actually
> doesn't occur.
URLﾘﾝｸ(marc.info)
1015:login:Penguin
20/06/05 14:07:47.91 jA3wZpDc.net
>>993 で引用された部分は
「ホントにc3aab9a0bd91なしだと起きないん？」「そだよ」
と言ってるだけだけど、
落ちるまでの流れはわかったっぽいしまだ不安定ながらパッチもできた、
というのが現状かな。
1016:login:Penguin
20/06/08 15:13:54.40 PPU2wP+g.net
>>994
で、もう正式に入れてちょうだいってパッチも出たんだけど、
実質1行追加するだけだった。
こういうパッチ好き。
実際どうかは知らないけど、いかにも問題を追求し切ったって感じがして。
1017:login:Penguin
20/06/13 14:52:24.01 Qx8FdC0t.net
次スレ
ｽﾚﾘﾝｸ(linux板)
1018:996
20/06/13 14:53:58.96 Qx8FdC0t.net
なぜか、NGに引っかかったので、関連スレの途中までしか書けていません。
あと、リンク切れの場合は、ご容赦ください。
1019:login:Penguin
20/06/13 14:54:55.61 Qx8FdC0t.net
次スレ
ファイルシステム総合スレ その18
ｽﾚﾘﾝｸ(linux板)
1020:login:Penguin
20/06/13 14:55:57.84 Qx8FdC0t.net
間違えた。
ファイルシステム総合スレ 「その19」
でした。
ｽﾚﾘﾝｸ(linux板)
1021:login:Penguin
20/06/13 14:56:51.52 Qx8FdC0t.net
ファイルシステム総合スレ その19
ｽﾚﾘﾝｸ(linux板)
1022:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 897日 15時間 6分 0秒
1023:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています