[過去ﾛｸﾞ]
ファイルシステム総合スレ その20 (1002ﾚｽ)
ファイルシステム総合スレ その20 http://mao.5ch.net/test/read.cgi/linux/1722312892/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
845: login:Penguin [sage] 2024/10/10(木) 23:56:09.82 ID:WGFMDZfJ 属性を保持したまま内容を一気に入れ替えるのは、今ならcopy_file_rangeがある http://mao.5ch.net/test/read.cgi/linux/1722312892/845
846: login:Penguin [sage] 2024/10/10(木) 23:57:11.07 ID:WGFMDZfJ で、こいつはCoWファイルシステムじゃないと本当に内容をコピーするので効率が悪い http://mao.5ch.net/test/read.cgi/linux/1722312892/846
847: login:Penguin [sage] 2024/10/11(金) 07:39:44.04 ID:/6otHtpl 停電を予測して スナップショットを撮る機能が追加されるとかしないとかいう話は聞いたことがない http://mao.5ch.net/test/read.cgi/linux/1722312892/847
848: login:Penguin [sage] 2024/10/11(金) 14:12:45.09 ID:mj4qPltc そこでNILFSですよ http://mao.5ch.net/test/read.cgi/linux/1722312892/848
849: login:Penguin [sage] 2024/10/11(金) 16:05:09.61 ID:P6k6G+uZ Nipple? http://mao.5ch.net/test/read.cgi/linux/1722312892/849
850: login:Penguin [sage] 2024/10/11(金) 22:21:34.48 ID:5hgxSCWq >>842 renameでのinode置き換えならunlinkはいらんし、user拡張属性なら転記するだけでいいけど何気にしてるか分からん http://mao.5ch.net/test/read.cgi/linux/1722312892/850
851: login:Penguin [sage] 2024/10/12(土) 00:50:45.17 ID:oiiqPhbz >>847 10年近く前にそんなファイルシステムを作ってたな 紆余曲折でプロジェクトはポシャったけど http://mao.5ch.net/test/read.cgi/linux/1722312892/851
852: login:Penguin [sage] 2024/11/01(金) 23:30:14.47 ID:fOkGcY4d openZFSの新しいDedupについて https://despairlabs.com/blog/posts/2024-10-27-openzfs-dedup-is-good-dont-use-it/ http://mao.5ch.net/test/read.cgi/linux/1722312892/852
853: login:Penguin [sage] 2024/11/02(土) 00:19:44.04 ID:VFPv/92F タイトルからして良いのか使うななのか。言いたい事は何故か分かった http://mao.5ch.net/test/read.cgi/linux/1722312892/853
854: login:Penguin [sage] 2024/11/02(土) 02:38:38.08 ID:QhRsNAf7 かなり改善されたけど一般的な使い方ではdedupを使う価値は無いとのこと http://mao.5ch.net/test/read.cgi/linux/1722312892/854
855: 警備員[Lv.21] [sage] 2024/11/21(木) 20:13:48.31 ID:84+fZx8I https://www.phoronix.com/news/Bcachefs-Uncertain-Kernel-Issue よりによってLinusが行動規範違反持ち出してワロス http://mao.5ch.net/test/read.cgi/linux/1722312892/855
856: login:Penguin [sage] 2024/11/21(木) 20:17:07.65 ID:irrhUSYn Linus先生の精神修養の効果はどれぐらい持続したんだろうか http://mao.5ch.net/test/read.cgi/linux/1722312892/856
857: login:Penguin [sage] 2024/11/21(木) 21:25:01.65 ID:IaoA0KbF カーネルは何千人も開発に関わってるプロジェクトだからな 問題があるメンテナは受け入れられないよ http://mao.5ch.net/test/read.cgi/linux/1722312892/857
858: login:Penguin [sage] 2024/11/22(金) 10:35:04.69 ID:NLeFvCAZ kent君が結構アレなので…… http://mao.5ch.net/test/read.cgi/linux/1722312892/858
859: 警備員[Lv.22] [sage] 2024/11/22(金) 11:21:03.37 ID:LsZKWQ6U https://www.phoronix.com/news/ReiserFS-Deleted-Linux-6.13 > ReiserFS Has Been Deleted From The Linux Kernel ついに…… それにしてもFS開発者ってキチガイ多くね？ http://mao.5ch.net/test/read.cgi/linux/1722312892/859
860: login:Penguin [sage] 2024/11/23(土) 10:44:13.64 ID:Suo8i6kX >>855 Bcachefs開発者がどんな行動規範違反しているのかかよくわからんのだけど LKMLでのKentのメール https://lore.kernel.org/lkml/citv2v6f33hoidq75xd2spaqxf7nl5wbmmzma4wgmrwpoqidhj@k453tmq7vdrk/ > Get your head examined. And get the fuck out of here with this shit. 訳: お前の脳みそ検査しろ。そのクソと一緒にここから出て行いきやがれ こういう5chみたいな文章がアウトってこと? http://mao.5ch.net/test/read.cgi/linux/1722312892/860
861: 警備員[Lv.1][新芽] [sage] 2025/01/25(土) 07:58:57.62 ID:woka93X8 zfsはせっかく良いファイルシステムなににちょっと勿体無いね http://mao.5ch.net/test/read.cgi/linux/1722312892/861
862: login:Penguin [sage] 2025/01/26(日) 03:10:14.41 ID:gS4o5s0d zfsはエンプラ用途すぎて中小企業や一般ユーザにはとても合わないと思うが http://mao.5ch.net/test/read.cgi/linux/1722312892/862
863: login:Penguin [sage] 2025/01/26(日) 13:22:39.12 ID:Wag9xtbO むしろ中小企業向けだろZFSは でかい企業は分散ファイルシステム使うだろうし http://mao.5ch.net/test/read.cgi/linux/1722312892/863
864: login:Penguin [sage] 2025/01/26(日) 19:09:51.48 ID:zsOq4jRe 中小企業は 1. 重複排除、スナップショット、圧縮が安定して使え 2. Active Directory の連携し CAL も不要、 3. 故障時ハードベンダーにお任せで社内技術者による属人化を無視可能 な中身がWindows IoT の NAS 製品買うでしょ。 エンタープライズも並列ファイルシステムの Lustre の中身 (ldiskfs(ext4) か ZFS が選択可能) として位ではないかな。 実績面で疑問が残る Lustre ZFS をまともに運用出来る人員を確保 できる組織が存在するかは疑問だが。 http://mao.5ch.net/test/read.cgi/linux/1722312892/864
865: 警備員[Lv.5][新芽] [sage] 2025/01/27(月) 11:47:32.08 ID:GOJgDLEA zfsよりbtrfsの方が勢いあるしな http://mao.5ch.net/test/read.cgi/linux/1722312892/865
866: login:Penguin [sage] 2025/01/27(月) 12:03:45.83 ID:K25csgYz NAS企業同士がexfat対btrfsで論争してなかったっけ、どうなったんだろ http://mao.5ch.net/test/read.cgi/linux/1722312892/866
867: login:Penguin [sage] 2025/01/27(月) 14:04:48.13 ID:xG3E2DwG ext4の間違いでは？ exfatなんて対抗にならないだろ http://mao.5ch.net/test/read.cgi/linux/1722312892/867
868: login:Penguin [sage] 2025/01/27(月) 14:26:13.82 ID:K25csgYz あ、素手間違えてたごめん もちろんext4 思い出そうとして今ぐぐったらQNAP、ReadyNAS、Synologyあたりが論争してたみたい http://mao.5ch.net/test/read.cgi/linux/1722312892/868
869: login:Penguin [sage] 2025/01/27(月) 19:01:01.79 ID:K2hOghs1 ext4ファイルシステム破損問題を思い出した ps://atmarkit.itmedia.co.jp/flinux/rensai/watch2009/watch11a.html http://mao.5ch.net/test/read.cgi/linux/1722312892/869
870: login:Penguin [sage] 2025/01/27(月) 19:30:01.39 ID:xG3E2DwG なんでそんな古い記事を つい2年くらい前にext4が壊れたことあっただろうに アプデですぐ治ったけど http://mao.5ch.net/test/read.cgi/linux/1722312892/870
871: login:Penguin [sage] 2025/01/27(月) 21:32:23.43 ID:thSG6MDn Synologyは関係ない。 ReadyNASとQNAPが煽り合ってたんだよ。 ReadyNAS Btrfsの先進性 - ReadyNASが先進的なファイルシステムBtrfsを採用している理由 https://www.netgear.jp/solutions/readynas/readynas_btrfs.html QNAP QNAP NASがBtrfsファイルシステムを使用しないのはなぜですか？ https://www.qnap.com/ja-jp/solution/qnap-ext4 http://mao.5ch.net/test/read.cgi/linux/1722312892/871
872: login:Penguin [sage] 2025/01/27(月) 21:40:18.97 ID:/u6c3b6/ QNAP君がBtrfsにグチグチ言ってるのは、こんなFS流行ったら非エンタープライズNASの商売上がったりだからかと思ったら煽り合う相手がいたのかw http://mao.5ch.net/test/read.cgi/linux/1722312892/872
873: 警備員[Lv.1][新芽] [sage] 2025/01/30(木) 00:46:22.22 ID:Mp6Sx01c 対抗馬のBcachefsはまだ実績なさすぎて使い物になるのはいつになる事やら http://mao.5ch.net/test/read.cgi/linux/1722312892/873
874: login:Penguin [sage] 2025/02/01(土) 15:37:29.88 ID:sek/ETxb openzfsがファイル名の1023バイト長に対応した 今までlinuxのまともなfsの中ではgpfsぐらいしか無かったから windowsとのinteropを気にしてる人にとっては朗報なんじゃ http://mao.5ch.net/test/read.cgi/linux/1722312892/874
875: login:Penguin [] 2025/02/02(日) 12:11:12.19 ID:MUcsqS+0 stdio.h で定義されているからコンパイル済のソフトじゃ使えんじゃん、 て思って調べてみたら結構前(CentOS6/手近にあった最古)でも FILENAME_MAX は 4096 だったわ。 http://mao.5ch.net/test/read.cgi/linux/1722312892/875
876: login:Penguin [sage] 2025/02/06(木) 22:00:39.54 ID:mnoX/Jvp ビットロット対応のFSふえてくれ winもmacも含めて http://mao.5ch.net/test/read.cgi/linux/1722312892/876
877: login:Penguin [sage] 2025/02/06(木) 22:22:11.87 ID:CxpOZANU ファイルシステム作る人、圧倒的に性格悪い説 zfs, ReiserFS, Bcachefs http://mao.5ch.net/test/read.cgi/linux/1722312892/877
878: login:Penguin [sage] 2025/02/07(金) 07:57:13.05 ID:kPy0cZmS なんで？ http://mao.5ch.net/test/read.cgi/linux/1722312892/878
879: login:Penguin [sage] 2025/02/07(金) 21:46:34.53 ID:0He1QcLs >>875 それはフルパスでは？ NAME_MAXがファイル名の規定のはず http://mao.5ch.net/test/read.cgi/linux/1722312892/879
880: login:Penguin [sage] 2025/02/10(月) 15:37:41.55 ID:ZXNyKkDA ext4の人は性格悪くないから単なる偶然だな zfsは知らん、reiserfsは妻殺し、bcachefsは手順も踏まず自己主張ばかりうるさい http://mao.5ch.net/test/read.cgi/linux/1722312892/880
881: login:Penguin [sage] 2025/02/10(月) 17:21:34.57 ID:qkuqaI2M zfs やOpen Solaris はCDDLで、GPLというかLinuxに成果を取られないようにイジワルしているとしか... 第6回 Debian 会議で Cooper は、Solaris カーネルを書いた技術者らが OpenSolaris が GPL 非互換となるよう要求したと述べている。「Mozilla が選ばれた理由のひとつとして、GPL非互換だからというのがある。 Common Development and Distribution License（CDDL） ps://ja.m.wikipedia.org/wiki/Common_Development_and_Distribution_License http://mao.5ch.net/test/read.cgi/linux/1722312892/881
882: login:Penguin [sage] 2025/02/10(月) 17:28:29.07 ID:5o8c5ISg コピーレフトなのにGPL非互換なライセンスか、こんなのあるんだな http://mao.5ch.net/test/read.cgi/linux/1722312892/882
883: login:Penguin [sage] 2025/02/10(月) 18:13:19.60 ID:ojBXykV6 ワイは作者さんの開発成果に世話になってるから感謝してる、性格はしらん http://mao.5ch.net/test/read.cgi/linux/1722312892/883
884: login:Penguin [sage] 2025/02/10(月) 19:35:37.99 ID:yWXuc1WU オラクルは邪悪 http://mao.5ch.net/test/read.cgi/linux/1722312892/884
885: login:Penguin [sage] 2025/02/12(水) 09:16:52.85 ID:iHlsRQuI >>879 NAME_MAXで正しいけどglibcでそれが問題になるような処理ってどこかにある？ 現実に問題になるのはPATH_MAXのほうだと思う 実際zfsで500文字ぐらいのファイル作って試してみてるけど今のところ問題ないな http://mao.5ch.net/test/read.cgi/linux/1722312892/885
886: login:Penguin [sage] 2025/02/28(金) 02:07:53.46 ID:aIUeCHvn encfsでwinのファイルがコピーできなくて困ったことならある http://mao.5ch.net/test/read.cgi/linux/1722312892/886
887: login:Penguin [sage] 2025/03/09(日) 19:18:19.92 ID:QVT5LwTm fedora のインストーラは btrfs を使う時、/boot 以外を一つのbtrfs パーティションとして作成してから、/ と /home をサブボリュームとしてマウントしている。 Debian のインストーラじゃ出来ない気がしている。 http://mao.5ch.net/test/read.cgi/linux/1722312892/887
888: login:Penguin [sage] 2025/03/09(日) 19:50:52.36 ID:z8Z+X9TG Debianだとbtrfsにすると/boot/efiを除く/以下全体がサブボリューム名@rootfsになる 細分化したいときはインストーラ終了後再起動前にライブイメージに居残って操作するといい http://mao.5ch.net/test/read.cgi/linux/1722312892/888
889: login:Penguin [sage] 2025/03/19(水) 19:52:54.67 ID:xxTg8g0q ファイルシステムって普通1つのファイルの最大サイズも〇〇バイトまでみたいな制限があると思いますが tmpfsにも1ファイルあたりの最大サイズとかって決まりみたいなのってありますか？ http://mao.5ch.net/test/read.cgi/linux/1722312892/889
890: login:Penguin [sage] 2025/03/20(木) 00:55:30.94 ID:y/r4L4bu 知らんけど仕様の制限より先にメモリサイズの制限のほうが先に来るだろう http://mao.5ch.net/test/read.cgi/linux/1722312892/890
891: login:Penguin [sage] 2025/05/28(水) 16:29:10.63 ID:A8s5L3lC +------------------------------------------+ | 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 http://mao.5ch.net/test/read.cgi/linux/1722312892/891
892: login:Penguin [sage] 2025/05/28(水) 16:29:29.58 ID:A8s5L3lC +-------------------------------------------------+ | E: 🔥迷い・目的の再評価 | | 🌱「分離故安全か？...だが切替煩雑」 | | 🌱「最悪時保険？...1.5年前状態に戻す価値薄」 | +-------------------------------------------------+ | v +-------------------------------------------------+ | F: 🎯目的変更・作業範囲縮小 | | 「今回は旧snapshotよりデータコピーのみに止む」 | +-------------------------------------------------+ | v +-------------------------------------------------+ | G: Copilot追認 | | (個別データ抽出・現環境維持を善策と評価) | | (btrfsサブボリューム複製、現環境と分離独立) | +-------------------------------------------------+ | v http://mao.5ch.net/test/read.cgi/linux/1722312892/892
893: login:Penguin [sage] 2025/05/28(水) 16:29:34.59 ID:A8s5L3lC +-------------------------------------------------+ | H: 過去の最悪事態経験想起 | | (timeshift --restore不能は稀有) | | (手動snapshotは最終保険として有効と認識) | +-------------------------------------------------+ | v +-------------------------------------------------+ | I: 最終結論・認識 | | 「苦労して整えし現環境を旧状態へ戻すは非得策」| | (現環境維持優先、旧データは必要時参照) | +-------------------------------------------------+ http://mao.5ch.net/test/read.cgi/linux/1722312892/893
894: login:Penguin [sage] 2025/06/01(日) 02:39:18.40 ID:+pBhduTU 似たようなファイルシステムがゴロゴロあるな 同じような機能同じような目的 http://mao.5ch.net/test/read.cgi/linux/1722312892/894
895: login:Penguin [] 2025/06/03(火) 13:06:05.98 ID:BLInsZ6k プロプラエタリィなNTFSの存在がガンですよ。 http://mao.5ch.net/test/read.cgi/linux/1722312892/895
896: login:Penguin [sage] 2025/06/06(金) 19:26:35.10 ID:DcwFmon4 btrfs と bcachefs ならどっちを使うべき？ http://mao.5ch.net/test/read.cgi/linux/1722312892/896
897: login:Penguin [sage] 2025/06/06(金) 22:04:20.08 ID:t2yseNZM (Linus Torvalds) in August of 2024 that "nobody sane uses bcachefs and expects it to be stable". ps://en.m.wikipedia.org/wiki/Bcachefs http://mao.5ch.net/test/read.cgi/linux/1722312892/897
898: login:Penguin [sage] 2025/06/06(金) 23:43:40.08 ID:DcwFmon4 >>897 草 Kent Overstreet 氏がなんかアレっぽいからやめとくわ http://mao.5ch.net/test/read.cgi/linux/1722312892/898
899: login:Penguin [sage] 2025/06/06(金) 23:49:44.94 ID:t2yseNZM An Initial Benchmark Of Bcachefs vs. Btrfs vs. EXT4 vs. F2FS vs. XFS On Linux 6.11 ps://www.phoronix.com/review/linux-611-filesystems http://mao.5ch.net/test/read.cgi/linux/1722312892/899
900: login:Penguin [sage] 2025/06/06(金) 23:57:09.45 ID:aNbcFT2d f2fsすげーな、SDカードいたわりファイルシステムってだけじゃないのか http://mao.5ch.net/test/read.cgi/linux/1722312892/900
901: login:Penguin [] 2025/06/07(土) 00:14:18.31 ID:7L+jxPfb F2FSはAndroidのストレージのファイルシステムに使われてるから 今はもうかなりのデバイス数で使われてる http://mao.5ch.net/test/read.cgi/linux/1722312892/901
902: login:Penguin [sage] 2025/06/07(土) 08:30:51.10 ID:4MW5fToT おもしろそうな話をしているようなのできました f2fsってのがあるんか http://mao.5ch.net/test/read.cgi/linux/1722312892/902
903: login:Penguin [sage] 2025/06/14(土) 07:11:03.75 ID:PyLZJCtn btrfsの更新履歴を読むと raid5 なら行けそうな気がしてきた。 http://mao.5ch.net/test/read.cgi/linux/1722312892/903
904: login:Penguin [] 2025/06/14(土) 18:45:45.76 ID:G4FNdXUC Raid5はもう使っても大丈夫になってたはず たしかLinux6.2から カーネルバージョン低いと注意 http://mao.5ch.net/test/read.cgi/linux/1722312892/904
905: login:Penguin [sage] 2025/06/14(土) 19:12:31.28 ID:mW9KbBLx RAID5まで使えるようになったらもうBtrfs敵無しでは？ http://mao.5ch.net/test/read.cgi/linux/1722312892/905
906: login:Penguin [sage] 2025/06/14(土) 19:37:59.71 ID:21r7Qhcw >>904 Debain 12 (Bookworm) 2023年は6.1なのでDebian 13(Trixie)からは大丈夫になるのか。良い情報だ。 http://mao.5ch.net/test/read.cgi/linux/1722312892/906
907: login:Penguin [sage] 2025/06/14(土) 19:44:51.93 ID:04hwReKF stableのカーネルって普通にbackportsのに 更新して使うものだと思ってた… 絶対にミスが許されない鯖とかでない限りは http://mao.5ch.net/test/read.cgi/linux/1722312892/907
908: login:Penguin [sage] 2025/06/14(土) 20:18:57.84 ID:21r7Qhcw レスチで悪いが、 Debian Backports に関しては Kernel で問題は出ないだろうけど、Backports でバージョン上げて不具合あっても、本家の解消待ちのイメージしかない。Emacs の事だが。 http://mao.5ch.net/test/read.cgi/linux/1722312892/908
909: login:Penguin [sage] 2025/06/15(日) 10:22:30.99 ID:xeQ27nWt >>904 なってません 追加機能無しで出来る修正が一つ入ったってだけで write holeは根本的に解決してないし 多分これからしばらくも解決されません ttps://www.phoronix.com/news/Linux-6.2-Btrfs-EXT4 ttps://www.reddit.com/r/btrfs/comments/127zmsx/what_do_you_think_about_the_kernel_62_btrfs/ そもそもRAID5実装自体が完全に安全だと仮定しても 何TBのHDDでRAID5とかはリビルド中にUREに遭う確率を考えると割に合わない http://mao.5ch.net/test/read.cgi/linux/1722312892/909
910: login:Penguin [sage] 2025/06/15(日) 10:34:47.25 ID:qAAeLG7f Btrfs使ってるけどRAID10で十分だよ http://mao.5ch.net/test/read.cgi/linux/1722312892/910
911: login:Penguin [] 2025/06/15(日) 15:02:24.57 ID:YaPsiovj リビルドなんてZFSでもそんな信頼性高いもんじゃないからどうでもいいわ なんか壊れたら素直に再構築すべき http://mao.5ch.net/test/read.cgi/linux/1722312892/911
912: login:Penguin [sage] 2025/06/15(日) 15:27:43.91 ID:aJl0W6/T リビルドによる冗長性に期待しないんだったら わざわざパリティ付きストライプで分散して書き込む理由なんて一つもない そして現実的な容量あたりの回復不可能エラーの確率を考えると 6はともかくまともな冗長性が期待出来ないRAID5なんか今は使う理由はまるでない それこそRAID1どころか多くの場合で破損部分が明白かつ単純で 無事な部分を吸える可能性が高い分だけシングル運用の方が遥かにマシ http://mao.5ch.net/test/read.cgi/linux/1722312892/912
913: login:Penguin [] 2025/06/15(日) 16:50:20.47 ID:YaPsiovj リビルドによる冗長性ってなに？ http://mao.5ch.net/test/read.cgi/linux/1722312892/913
914: login:Penguin [sage] 2025/06/15(日) 17:08:32.78 ID:6DNeCkGf RAIDはアレイが破損したらリビルドかける前に 全データバックアップしろが通説だと思った バックアップする空きストレージがないとか そもそもバックアップがないなら そもそもその運用がおかしい… (捨ててもいいデータだけとか観て消し録画は除く) http://mao.5ch.net/test/read.cgi/linux/1722312892/914
915: login:Penguin [sage] 2025/06/15(日) 17:27:55.30 ID:xQc9M6ba なんでRAIDやりたがるのか意味不明 バックアップの工夫をそれなりにやって ダウンタイムやデータ損失期間を減らすための最終仕上げだよね それとも広告であるネット記事を見て導入が大半? http://mao.5ch.net/test/read.cgi/linux/1722312892/915
916: login:Penguin [sage] 2025/06/15(日) 17:35:50.44 ID:aJl0W6/T >>913 ttps://e-words.jp/w/%E5%86%97%E9%95%B7%E6%80%A7.html ttps://www.buffalo.jp/topics/trouble/detail/recovery_0005.html RAIDの文脈で「冗長性」ってのは RAID構成内に故障したハードウェアが出てもデータの完全性が損なわれない事 「リビルド」ってのはもっぱらその故障したハードウェアを入れ替えて元の冗長性を持つ構成に再構築することを指す この説明でわかんないんだったら俺にはうまく説明出来ねえ 「リビルドできる冗長性に～」の方がもっと正確な言い回しだったといえばそれはそうなので わかってて言ってたら単に俺の日本語が下手でごめんだな >>914-915 本当にクリティカルなデータを扱うなら 定時記録的なオフラインバックアップが常に別にあって 「退避」や「サルベージ」をやる必要すらほぼ無いのが理想だし本当なら当然 もちろん実現にはハードウェアも運用もコストが相応に要るので難しくなるけどね 冗長性が無い状態での改めての読み出しは 結局リビルドとやってる事は似てて当然ながらもし残りのハードウェアが故障すれば(読み出せなくなった分は)完全にパーなんで これはどちらかというと現実的な次善策 それこそbtrfsならスナップショットとsend/receiveをうまく使えば オフラインバックアップ用の場所にも高速に増分バックアップ出来るよ http://mao.5ch.net/test/read.cgi/linux/1722312892/916
917: login:Penguin [] 2025/06/15(日) 18:37:25.91 ID:YrR/Ub7i btrfsのsnapは呆気ないほど簡単にファイルの先祖返りが長期も短期も可能で、 WinがやっているVolume Shadow Copyの上位互換って印象で、個人的にはとても好き。 でも、バックアップは別途必要かなって思っている。神経質なだけかもだけれど、データって一番大事だから増分・差分だけじゃなく、本体も自分は保持するようにしている。 http://mao.5ch.net/test/read.cgi/linux/1722312892/917
918: login:Penguin [] 2025/06/15(日) 21:04:14.45 ID:YaPsiovj >>916 冗長性ってリビルドのためではなくサービスを止めないためのものでは？ リビルドしなくても冗長性は重要だよ http://mao.5ch.net/test/read.cgi/linux/1722312892/918
919: login:Penguin [sage] 2025/06/15(日) 21:36:30.54 ID:xQc9M6ba びっくりしたのはRAIDでリビルド機能が無いと言われたとき そりゃまぁデータ消えないけどそのまま運用とか狂人だろうに おーこわいこわい http://mao.5ch.net/test/read.cgi/linux/1722312892/919
920: login:Penguin [sage] 2025/06/15(日) 21:39:54.36 ID:nO4JLxoc >>917 btrfsなら親になるスナップショットを指定して増分モードでsend/receive出来るから 外部にも、 つまり「バックアップ」もスナップショット構造を維持しながら 書き込みは増分だけで済むよって話なんだ 例えばオリジナル上でSnapperで毎日撮ってて06-15→06-16→06-17とかあるとして 同一の06-15が送受信するストレージ上に同時にあれば それを親に指定して06-16は差分だけ転送で済む そして06-16が同時にあればそれを親にして06-17は差分だけで……で継ぎ足し出来るわけさ ttps://btrfs.readthedocs.io/en/latest/Send-receive.html >>918 だから「RAIDの文脈で」って前置きして例のURLまで出してるでしょ 「RAIDの文脈で言う『冗長性』は主にはグループのうちn台が故障してもデータの完全性を保ち、そこからリビルドが出来る事」であって 例えば何かしらサーバーとして運用されてる物ならその全体の可用性として 一般的な語句で言う「冗長性」が望ましいというのは事実だしあんたは何も間違ってないけど それはファイルシステムとデータだけに留まらない話 「たとえリビルドをしなくても全体の冗長性が重要」なんてのはそりゃ当然だけど ファイルシステム総合スレなんだから 第一にファイルシステムとそれに関連するデータ保存の目的の文脈で話をしてるに決まってるじゃん http://mao.5ch.net/test/read.cgi/linux/1722312892/920
921: login:Penguin [sage] 2025/06/16(月) 02:21:59.35 ID:upbk3sl3 リビルドは最初からあまり期待しない。 HDDがいかれたときは他のHDDも寿命間近で、リビルド中にお釈迦になった経験がある。 raidを使う利点はコントローラから警告音が盛大に出ることとバックアップの時間が稼げること。 ソフトウェアraidの利点も時間稼ぎかな。 http://mao.5ch.net/test/read.cgi/linux/1722312892/921
922: login:Penguin [] 2025/06/16(月) 03:30:56.52 ID:V26EfEYC 業務用ストレージならスクラブが走るからリビルドあんま失敗しないけどね 最近は別の不具合でボリュームが全損するケースがちらほらある ストレージも最近高いくせに品質悪いな http://mao.5ch.net/test/read.cgi/linux/1722312892/922
923: login:Penguin [] 2025/06/16(月) 05:44:18.12 ID:zRTb+SAk RAID1ならリビルドするけどRAID5や6はやらないかなあ 時間かかりすぎるよ http://mao.5ch.net/test/read.cgi/linux/1722312892/923
924: login:Penguin [] 2025/06/16(月) 07:30:45.29 ID:7sPaAkac > バックアップの時間が稼げる これが大事だと思う http://mao.5ch.net/test/read.cgi/linux/1722312892/924
925: login:Penguin [sage] 2025/06/16(月) 07:45:29.75 ID:upbk3sl3 時間稼ぎだからデータ逃がせる環境ならraid5で十分だよ。 http://mao.5ch.net/test/read.cgi/linux/1722312892/925
926: login:Penguin [sage] 2025/06/16(月) 12:57:40.92 ID:7WvLU0an リビルドせずにバックアップ取得 ならRAID不要の環境だし普段からバックアップしとけよ どれだけ踊らされているのか http://mao.5ch.net/test/read.cgi/linux/1722312892/926
927: login:Penguin [] 2025/06/16(月) 16:46:19.63 ID:zRTb+SAk >>926 どういうこと？ リアルタイムバックアップしろってこと？ http://mao.5ch.net/test/read.cgi/linux/1722312892/927
928: login:Penguin [sage] 2025/06/17(火) 03:11:16.03 ID:G5q8UCPD バックアップは毎日取るものでしょ 差分だけなら時間もわずかなので なんでRAID縮退時にバックアップを取る前提なの? 普段からとってないの? http://mao.5ch.net/test/read.cgi/linux/1722312892/928
929: login:Penguin [] 2025/06/17(火) 04:39:39.96 ID:Z0BbVoQp 日に一度のバックアップならやっぱりRAID必要やん なぜそれでRAID不要になるのか http://mao.5ch.net/test/read.cgi/linux/1722312892/929
930: 875 [sage] 2025/06/17(火) 09:00:11.26 ID:lZRqBMI7 「壊れた瞬間に使えなくなる」のか、「まだ使える/処理を継続 できる」のか、はかなり重要なファクターだと思うが？ 流石にバックアップあればRAID不要は極論。 ハードウェアRAIDはスクラブやらSMART監視で部分的な故障まで 監視しているからリビルド失敗はない。 失敗した場合でもRAIDカード交換させたら治ったこともあるから 似たようなことがったらカード交換も検討するといいよ。 LVM,ファイルシステム,デバイスドライバーによるソフトウェアRAID やらフェイクRAIDも「４～５年ごとにハードを買い替える」ことが 守れてば大丈夫だと思うけどねぇ。 http://mao.5ch.net/test/read.cgi/linux/1722312892/930
931: login:Penguin [sage] 2025/06/17(火) 09:22:17.66 ID:G5q8UCPD 優先度について述べているだけ バックアップを定期的に取らないのにRAID導入しているのが見受けられる http://mao.5ch.net/test/read.cgi/linux/1722312892/931
932: login:Penguin [sage] 2025/06/17(火) 10:22:28.94 ID:lZRqBMI7 バックアップに対する現場の意識が足りない、という意味で言いたいのは わからんでもないが、データロストと(RAIDなし環境における)業務/納期 遅延のそれぞれリスクを発生確率を交えて考えると、やはりその意見には 賛同できないよ。 http://mao.5ch.net/test/read.cgi/linux/1722312892/932
933: login:Penguin [sage] 2025/06/17(火) 10:29:03.82 ID:YcGRWNVI 一切の故障がなくてもURE(回復不可能な読み取りエラー)は確率的に起きるのでまず前提が間違ってる もちろん製品のグレードによりけりで エンタープライズ用HDDなら限りなく低い確率、具体的には10^15ビットに1回になるぐらいの品質で製造されてるけど どのHDDにも起き得るし一般的な民生用だと10^14ビットに1回程度で更に確率が上がる TB単位のストレージでRAID5が現実的じゃないってのは 読み取るサイズが増える分だけURE=リビルド失敗の可能性が高まるから 8TBだと仮定して民生用だと約60%、エンタープライズ用でも約6％ぐらいの確率で失敗する可能性がある んでRAID1なら片肺でも読み出し出来るし リトライも容易だけどRAID5じゃそうはいかねー事が多いからな http://mao.5ch.net/test/read.cgi/linux/1722312892/933
934: login:Penguin [sage] 2025/06/17(火) 11:49:56.28 ID:fFPZtW+I RAID5,6は理論上の速度や容量効率は利点だけど、 データチャンク、XORパリティで細切れブロック配置したり複雑で ディスク上のビット単位でのデータ信頼性という意味では 物理ヘッドガチャガチャするHDDではRAID0よりキツそう (そんなに詳しくないから想像だけど) 実際には様々なレイヤーのパリティやビット訂正で エラー回復してるんだろうけど、自分が使ってる RAID1(Btrfs)でさえ3週に1度スクラブかけると 半分ぐらいの確率でエラー訂正しましたのログが残ってるのだわ http://mao.5ch.net/test/read.cgi/linux/1722312892/934
935: login:Penguin [] 2025/06/17(火) 12:00:27.91 ID:G5q8UCPD URE(回復不可能な読み取りエラー) というのは媒体mediumエラーでしょ? HDD/SSDコントローラは生きていて 特定LBA(LogicalBlockAddress)でエラーがでる 局所的ブロック、媒体エラーだよね HDD/SSD内部でソフトウェア的エラーの可能性はあるけど カーネルから見たらハードウェアエラー(==故障)だよ これ範 http://mao.5ch.net/test/read.cgi/linux/1722312892/935
936: login:Penguin [] 2025/06/17(火) 12:02:38.15 ID:G5q8UCPD あとRAID使っているわりには ファンや電源の冗長化してないよね これらも故障したら交換するまで停止でしょ http://mao.5ch.net/test/read.cgi/linux/1722312892/936
937: login:Penguin [sage] 2025/06/17(火) 12:12:08.12 ID:fFPZtW+I >>933 言われてみればそうだなあ… HDDだけダウンタイムなしまたは交換時間オンリーを想定してても、 HDDの故障率と比べて電源やファンとかM/B等パーツが それより壊れないかと言うとうーんって思う… 自分の環境はファンは予備があってすぐ交換できるし、 電源はACアダプターのマザボ運用してるのでちょっとマシ (ノート用のよくある19VでOK) http://mao.5ch.net/test/read.cgi/linux/1722312892/937
938: login:Penguin [] 2025/06/17(火) 12:57:44.98 ID:G5q8UCPD >>933 は事実と異なる内容を記述している あるHDD/SSDでURE(回復不可能な読み取りエラー)が出たら RAIDレベルによらず全HDD/SSD稼働中なら他のHDD/SSDのデータから復元できる (要は1台故障と同じ(切り離して故障にするかは別問題でコントローラの設計)) HDD/SSD故障があるのならRAIDレベルによらず多重故障でデータ復元できない RAID6は2点故障でも復元できるけど http://mao.5ch.net/test/read.cgi/linux/1722312892/938
939: login:Penguin [sage] 2025/06/17(火) 13:27:54.93 ID:lZRqBMI7 現場的には6%はかなり盛り過ぎだと感じるわ。 RAID のチャンクサイズ考慮して計算されてないか、 スクラブとかSMART監視とかない前提？ http://mao.5ch.net/test/read.cgi/linux/1722312892/939
940: login:Penguin [sage] 2025/06/17(火) 13:37:46.66 ID:1K0szjjx >>938 だから「リビルドがUREで失敗する確率は決して低くない」という話だって言ってるじゃん 冗長性のあるRAIDレベルで通常稼働時に単一の障害が訂正出来るのは当たり前じゃねーかw >>939 あくまで「リビルド中にUREに遭遇する確率」をカタログスペックから単純計算(概算)した数字の話なので もちろん実際の障害の可能性はもう少し前後し得るよ 改めて補足しとくけどUREはSMARTとかからわかる形で 明確に「故障」せずとも読み取り時に偶発的に起きる確率的現象で だから市販製品のデータシートにもちゃんと書いてあるんだ(Non-recoverable errors per bits readの項とかその辺り) もちろん業務用途ならHDD/SSDにしろRAIDカードにしろソフトウェアRAIDにしろ ずっと上等で堅牢な構成を採用してる事が多いから 破滅的な結果に至る確率はぐっと低いよ あくまで典型的には個人がRAID5やるシナリオだと致命的になりがちって話ね ttps://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/product/internal-drives/wd-red-plus-hdd/product-brief-western-digital-wd-red-plus-hdd.pdf ttps://www.seagate.com/files/www-content/product-content/hdd-fam/seagate-archive-hdd/en-us/docs/archive-hdd-dS1834-3-1411us.pdf http://mao.5ch.net/test/read.cgi/linux/1722312892/940
941: login:Penguin [] 2025/06/17(火) 13:51:35.52 ID:G5q8UCPD 5分停止したら何億とか会社消滅ならRAIDでサービス継続は分かる でも個人用途ではHDD故障して機能のバックアップで十分 データ書き戻しで半日くらい止まっても大丈夫 これらが大半 RAID不要だろって話 webや雑誌記事でのせられて使っているだけでしょ? http://mao.5ch.net/test/read.cgi/linux/1722312892/941
942: login:Penguin [] 2025/06/17(火) 13:52:18.30 ID:G5q8UCPD 昨日のバックアップデータで許容ね http://mao.5ch.net/test/read.cgi/linux/1722312892/942
943: login:Penguin [sage] 2025/06/17(火) 14:22:03.02 ID:89jEObby linux板って個人と企業を混合して話をするからエスパー力を必要とされるね http://mao.5ch.net/test/read.cgi/linux/1722312892/943
944: login:Penguin [sage] 2025/06/17(火) 16:34:21.29 ID:TRstYWTQ >>934 3週間間隔でエラー補正かかる、は流石にディスクの方を疑おうよ… http://mao.5ch.net/test/read.cgi/linux/1722312892/944
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 58 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.017s