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:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています