[過去ﾛｸﾞ] ファイルシステム総合スレ その20 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
884: 02/10(月)19:35 ID:yWXuc1WU(1) AAS
オラクルは邪悪
885: 02/12(水)09:16 ID:iHlsRQuI(1) AAS
>>879
NAME_MAXで正しいけどglibcでそれが問題になるような処理ってどこかにある？
現実に問題になるのはPATH_MAXのほうだと思う
実際zfsで500文字ぐらいのファイル作って試してみてるけど今のところ問題ないな
886: 02/28(金)02:07 ID:aIUeCHvn(1) AAS
encfsでwinのファイルがコピーできなくて困ったことならある
887: 03/09(日)19:18 ID:QVT5LwTm(1) AAS
fedora のインストーラは btrfs を使う時、/boot 以外を一つのbtrfs パーティションとして作成してから、/ と /home をサブボリュームとしてマウントしている。
Debian のインストーラじゃ出来ない気がしている。
888: 03/09(日)19:50 ID:z8Z+X9TG(1) AAS
Debianだとbtrfsにすると/boot/efiを除く/以下全体がサブボリューム名@rootfsになる
細分化したいときはインストーラ終了後再起動前にライブイメージに居残って操作するといい
889: 03/19(水)19:52 ID:xxTg8g0q(1) AAS
ファイルシステムって普通1つのファイルの最大サイズも〇〇バイトまでみたいな制限があると思いますが
tmpfsにも1ファイルあたりの最大サイズとかって決まりみたいなのってありますか？
890: 03/20(木)00:55 ID:y/r4L4bu(1) AAS
知らんけど仕様の制限より先にメモリサイズの制限のほうが先に来るだろう
891: 05/28(水)16:29 ID:A8s5L3lC(1/3) AAS
+------------------------------------------+
| A: Btrfs Send/Receive再利用試験 |
| (長期不使用機能、試験欲す) |
| (元snapshot: /timeshift/.../@, @home) |
+------------------------------------------+
|
v
+------------------------------------------+
| B: 現状確認・Snapshot所在確認 |
| (lsblk, mount /dev/sda1, ls) |
| (先ディスクにて発見: |
| /mnt/backup_btrfs/@_snapshot, |
| @home_snapshot) |
+------------------------------------------+
|
v
+------------------------------------------+
| C: 手動復元手順の複雑性再認識 |
| (fstab, grub, initramfs等手作業多) |
| (timeshift自動復元との対比) |
+------------------------------------------+
|
v
+------------------------------------------+
| D: `btrfs subvolume snapshot` の |
| 非破壊性確認 (Copilot助言) |
| (操作自体は安全、然しmount/fstab変更 |
| 伴えば現環境復帰煩雑の可能性) |
+------------------------------------------+
|
v
892: 05/28(水)16:29 ID:A8s5L3lC(2/3) AAS
+-------------------------------------------------+
| E: 🔥迷い・目的の再評価 |
| 🌱「分離故安全か？...だが切替煩雑」 |
| 🌱「最悪時保険？...1.5年前状態に戻す価値薄」 |
+-------------------------------------------------+
|
v
+-------------------------------------------------+
| F: 🎯目的変更・作業範囲縮小 |
| 「今回は旧snapshotよりデータコピーのみに止む」 |
+-------------------------------------------------+
|
v
+-------------------------------------------------+
| G: Copilot追認 |
| (個別データ抽出・現環境維持を善策と評価) |
| (btrfsサブボリューム複製、現環境と分離独立) |
+-------------------------------------------------+
|
v
893: 05/28(水)16:29 ID:A8s5L3lC(3/3) AAS
+-------------------------------------------------+
| H: 過去の最悪事態経験想起 |
| (timeshift --restore不能は稀有) |
| (手動snapshotは最終保険として有効と認識) |
+-------------------------------------------------+
|
v
+-------------------------------------------------+
| I: 最終結論・認識 |
| 「苦労して整えし現環境を旧状態へ戻すは非得策」|
| (現環境維持優先、旧データは必要時参照) |
+-------------------------------------------------+
894: 06/01(日)02:39 ID:+pBhduTU(1) AAS
似たようなファイルシステムがゴロゴロあるな
同じような機能同じような目的
895: 06/03(火)13:06 ID:BLInsZ6k(1) AAS
プロプラエタリィなNTFSの存在がガンですよ。
896: 06/06(金)19:26 ID:DcwFmon4(1/2) AAS
btrfs と bcachefs ならどっちを使うべき？
897(1): 06/06(金)22:04 ID:t2yseNZM(1/2) AAS
(Linus Torvalds) in August of 2024 that "nobody sane uses bcachefs and expects it to be stable".
外部ﾘﾝｸ:en.m.wikipedia.org
898: 06/06(金)23:43 ID:DcwFmon4(2/2) AAS
>>897
草
Kent Overstreet 氏がなんかアレっぽいからやめとくわ
899: 06/06(金)23:49 ID:t2yseNZM(2/2) AAS
An Initial Benchmark Of Bcachefs vs. Btrfs vs. EXT4 vs. F2FS vs. XFS On Linux 6.11
外部ﾘﾝｸ:www.phoronix.com
900: 06/06(金)23:57 ID:aNbcFT2d(1) AAS
f2fsすげーな、SDカードいたわりファイルシステムってだけじゃないのか
901: 06/07(土)00:14 ID:7L+jxPfb(1) AAS
F2FSはAndroidのストレージのファイルシステムに使われてるから
今はもうかなりのデバイス数で使われてる
902: 06/07(土)08:30 ID:4MW5fToT(1) AAS
おもしろそうな話をしているようなのできました
f2fsってのがあるんか
903: 06/14(土)07:11 ID:PyLZJCtn(1) AAS
btrfsの更新履歴を読むと raid5 なら行けそうな気がしてきた。
904(2): 06/14(土)18:45 ID:G4FNdXUC(1) AAS
Raid5はもう使っても大丈夫になってたはず
たしかLinux6.2から
カーネルバージョン低いと注意
905: 06/14(土)19:12 ID:mW9KbBLx(1) AAS
RAID5まで使えるようになったらもうBtrfs敵無しでは？
906: 06/14(土)19:37 ID:21r7Qhcw(1/2) AAS
>>904
Debain 12 (Bookworm) 2023年は6.1なのでDebian 13(Trixie)からは大丈夫になるのか。良い情報だ。
907: 06/14(土)19:44 ID:04hwReKF(1) AAS
stableのカーネルって普通にbackportsのに
更新して使うものだと思ってた…
絶対にミスが許されない鯖とかでない限りは
908: 06/14(土)20:18 ID:21r7Qhcw(2/2) AAS
レスチで悪いが、
Debian Backports に関しては Kernel で問題は出ないだろうけど、Backports でバージョン上げて不具合あっても、本家の解消待ちのイメージしかない。Emacs の事だが。
909: 06/15(日)10:22 ID:xeQ27nWt(1) AAS
>>904
なってません
追加機能無しで出来る修正が一つ入ったってだけで
write holeは根本的に解決してないし
多分これからしばらくも解決されません
外部ﾘﾝｸ:www.phoronix.com
外部ﾘﾝｸ:www.reddit.com
そもそもRAID5実装自体が完全に安全だと仮定しても
何TBのHDDでRAID5とかはリビルド中にUREに遭う確率を考えると割に合わない
910: 06/15(日)10:34 ID:qAAeLG7f(1) AAS
Btrfs使ってるけどRAID10で十分だよ
911: 06/15(日)15:02 ID:YaPsiovj(1/3) AAS
リビルドなんてZFSでもそんな信頼性高いもんじゃないからどうでもいいわ
なんか壊れたら素直に再構築すべき
912: 06/15(日)15:27 ID:aJl0W6/T(1/2) AAS
リビルドによる冗長性に期待しないんだったら
わざわざパリティ付きストライプで分散して書き込む理由なんて一つもない
そして現実的な容量あたりの回復不可能エラーの確率を考えると
6はともかくまともな冗長性が期待出来ないRAID5なんか今は使う理由はまるでない
それこそRAID1どころか多くの場合で破損部分が明白かつ単純で
無事な部分を吸える可能性が高い分だけシングル運用の方が遥かにマシ
913(1): 06/15(日)16:50 ID:YaPsiovj(2/3) AAS
リビルドによる冗長性ってなに？
上下前次1-新書関写板覧索設栞歴
あと 89 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.019s