[過去ﾛｸﾞ]
ファイルシステム総合スレ その20 (1002ﾚｽ)
ファイルシステム総合スレ その20 http://mao.5ch.net/test/read.cgi/linux/1722312892/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
1: login:Penguin [sage] 2024/07/30(火) 13:14:52.24 ID:mzddZTqJ ● 前スレ ファイルシステム総合スレ その18 https://mao.5ch.net/test/read.cgi/linux/1514472651/l50 ファイルシステム総合スレ その19 https://mao.5ch.net/test/read.cgi/linux/1592027147/ ● 関連スレ ジャーナリングファイルシステム https://mevius.5ch.net/test/read.cgi/unix/979408065/l50 OpenSolaris/Illumos (OpenIndiana, etc.) 6 https://mevius.5ch.net/test/read.cgi/unix/1337411922/l50 FS関連スレ https://medaka.5ch.net/test/read.cgi/os/1137387538/l50 過去スレ, 関連リンクは >>2-10 あたりで. http://mao.5ch.net/test/read.cgi/linux/1722312892/1
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
945: login:Penguin [sage] 2025/06/17(火) 19:12:51.70 ID:lZRqBMI7 以下チラ裏。 週１回スクラブ、週の書き込みが総容量の15%程度でディスクの 使用率90%、8TBx11本(10d1p)、エラー率1/10^15、と仮定して 自分で計算してみた。 10d1pでスクラブなしで１本故障時に残存HDDにエラーが乗って いる率(任意の10本にエラーが乗っている確率)が8%。 スクラブで 0.00000000028% に低下(面倒なので0%とする)。 １週間分の書き込みで 1.2% に上昇、 未使用領域で事なきを得る確率 10% を差っ引くとリビルド失敗率は 1.08% だな。 個人だとHDD4本構成(3d1p)ぐらい？。 ディスク使用率70%、エラー率は1/10^14 で週の書込量は総容量の 3% で計算。 スクラブなしだと任意の３本にエラーが乗っている確率が24%、 こちらも週１回スクラブ(TeraStationとかがこれぐらいの頻度？) でほぼゼロに。 週に３%(0.72TB)書込で 0.72%、未使用領域で事なきをえる確率 30% 差っ引いてリビルド失敗率は 0.5% ぐらいか。 http://mao.5ch.net/test/read.cgi/linux/1722312892/945
946: login:Penguin [sage] 2025/06/17(火) 19:17:43.68 ID:526FSu8J お前らいったん冷静になってスレタイ512回ほど音読しろ http://mao.5ch.net/test/read.cgi/linux/1722312892/946
947: login:Penguin [sage] 2025/06/17(火) 19:47:46.56 ID:YcGRWNVI みんなbtrfsの話してるとばかり思ってたのに あ、個人の趣味でbtrfsでRAID1してます http://mao.5ch.net/test/read.cgi/linux/1722312892/947
948: login:Penguin [sage] 2025/06/17(火) 19:48:20.77 ID:0tWlbWzs まあまあ… ファイルシステムを乗せるための ファイルシステム/データストレージ関連技術として RAIDとかLVMとかの話題もいいんじゃない？ 専用スレも無いみたいだし(それまで過疎ってたし…) http://mao.5ch.net/test/read.cgi/linux/1722312892/948
949: login:Penguin [sage] 2025/06/17(火) 21:52:54.92 ID:YcGRWNVI >>945 Unrecoverable Read Error (URE)は言葉の通り「回復不可能な読み出しエラー」、 つまり読み出しの時点で新たに起きるエラーの話で URE rate (URE率)というのは読み出しの総量に対してエラーが起きる確率 つまり厳密には事前の書き込みで起きる破損(破損セクタ)じゃないよ 適切に定期scrubすれば現実の故障のリスクを減らせると思われるのはその通りだけど それ踏まえても「リビルド時のURE 」は無くせないって話 でも先の60%/6%で失敗って言ったのはカタログスペックの保守的な見積もり(のはずの)保証値から全容量でざっくり概算したもので 実際のHDDのエラー率はもっと低いだろって指摘する人もいるし もっと楽観的に見れるんじゃねと言えばそれはそうだと思う 繰り返しになるけど俺が言いたいのは「"RAID5は" URE考えるとヤバイ」って所ね RAID1はじめscrubなど適切な運用ありきの多くが 現実的じゃないとはまったく思ってないし言ってもないからね ttps://www.enricobassetti.it/2022/03/raid5-ure-and-the-probability/ 長々ほぼスレチ話しちゃったから無理やり話戻すけど btrfsでRAID5だけは絶対やめとけ 地雷機能の地雷構成とか絶対死ぬでw ttps://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices http://mao.5ch.net/test/read.cgi/linux/1722312892/949
950: login:Penguin [sage] 2025/06/17(火) 23:13:16.50 ID:G5q8UCPD ひとのコメントを根拠とか示さず貼られても… RAID5ではこれこれの機能が理論的には必要だけど linux mdはこれこれが実装されていないとか 具体的に書けばよいのに http://mao.5ch.net/test/read.cgi/linux/1722312892/950
951: login:Penguin [sage] 2025/06/17(火) 23:54:33.35 ID:YcGRWNVI え、まだ続けんのこの話？？？ どういう実装(ハードウェア/ソフトウェア)でもRAID5は原理的にクラッシュ時のwrite hole(データ/パリティの不整合)の時の問題があるから 電源周りなら例えばUPSで確実にセーフシャットダウン出来るとか バッテリーバックアップ(キャッシュ)付きのハードウェアRAIDとかが推奨に近いレベルであるべきだし ソフトウェアRAIDなら何かしらトランザクションログ付き(ZFSのRAIDZがこれ)になってるとか それでも偶発的なクラッシュによる中断はあり得るとか 何にしても「安全な運用」はかなり難しいか 出来るとしても少なくともかなり上等な環境と管理者が要ると思いますけど てかmdadm含め「RAID」全体だと厳密にはスレチなんじゃねーの？？？ Linux板のファイルシステム総合スレなんだからさあ RAID機能の話ならbtrfsとかOpenZFSとかの話をするスレなんじゃないのか んでbtrfsならまさにwrite hole問題を軽減する実装に乏しいから RAID5(と6)は現状やめときって評価なんじゃないの？ なんか間違ったこと言ってる？ http://mao.5ch.net/test/read.cgi/linux/1722312892/951
952: login:Penguin [sage] 2025/06/18(水) 00:21:52.57 ID:kTzkFbG6 write holeはRAID1でも起こり得るのだが… Disk1だけ書き込めてDisk0は書き込めない状況 両ディスクで内容が異なる http://mao.5ch.net/test/read.cgi/linux/1722312892/952
953: login:Penguin [sage] 2025/06/18(水) 00:33:26.16 ID:CeuUJCLk write holeあったとしてもbtrfsはRAID1でもチェックサムあるからスクラブで修正出来るんじゃないの？ http://mao.5ch.net/test/read.cgi/linux/1722312892/953
954: login:Penguin [sage] 2025/06/18(水) 00:44:06.13 ID:6FJRmKfA RAID1でもwrite holeそのものは起こるけど ミラーリングは単にどちらか片方のコピーが正しい可能性が高く btrfsなら今あるメタデータとチェックサムだけでスクラブで十分に修正出来る 対して5/6はストライプ+パリティで仕組みが複雑なので 最悪アレイが丸ごとおじゃんになる可能性がある http://mao.5ch.net/test/read.cgi/linux/1722312892/954
955: login:Penguin [sage] 2025/06/18(水) 10:37:09.61 ID:wvNgIh7z >>951 > なんか間違ったこと言ってる？ 「Btrfs のRAID-5は危険だから使うな」は間違いかな。 「どうして TeraStation や QNAP は RAID-5 で炎上していない んだ」、「炎上しないために何をすれば良いんだ」、 「本当のリビルドの失敗率はどれくらいなんだ」、「ファイル システムのジャーナリングがライトホールに対してどれだけ有効 か/無力か」あたりを突き詰めるのが正解じゃね？ なんか根拠で碌に精度も出せてないのにバッサリ「使うな」って 雑な結論ゴリゴリ押しつけてくるだけって感じる。 http://mao.5ch.net/test/read.cgi/linux/1722312892/955
956: login:Penguin [sage] 2025/06/18(水) 13:29:48.18 ID:f4q6cLid ↑951じゃないけど横からちょっとだけ 少なくともQNAPのRAID5は「Btrfsの内蔵機能」での RAID5じゃなくて、MD機能を使ったRAIDですのだ… (最近のQNAPではさらにLVMのレイヤーも噛ませてた気も) 「Btrfsの」RAID5(RAID6も?)は、少なくとも カーネル6.1とかの段階では、メンテナー自身が 危険だからデバッグ目的以外で使うなって言ってた MDを使ったソフトウェアRAIDはもう枯れまくってて 自身の機能部分での安定性は実績がある… けど拡張性や柔軟性は現在基準では比較でやはり厳しい感 http://mao.5ch.net/test/read.cgi/linux/1722312892/956
957: login:Penguin [sage] 2025/06/18(水) 14:06:13.70 ID:K/MF2oNs これか？ Linux 6.2カーネルに含めるためにBtrfsの改善が提案されました RAID 5/6 実装での書き込みホールの問題を修正します。 https://ja.linuxadictos.com/Linux-6-2.html https://en.linuxadictos.com/Linux-6-2.html RAID5/6 の場合、ファイル システムはチェックサムを保存しません。 この場合、ファイル システムは読み取り-変更-書き込み (RMW) 操作を実行する必要があります。 開発者は、RMW 操作がこの操作を実行する前にブロックのチェックサムを検証し、必要に応じてデータ リカバリが書き込み後にチェックサム検証も実行するように変更を加えました。 残念ながら、不完全なフリンジ (RMW) が書き込まれる状況では、これによりチェックサムを計算するための追加のオーバーヘッドが発生しますが、信頼性が大幅に向上します。 RAID6 の場合、そのようなロジックはまだ準備ができていません。 http://mao.5ch.net/test/read.cgi/linux/1722312892/957
958: login:Penguin [sage] 2025/06/18(水) 14:33:29.88 ID:mS/Jtlgs 今のbtrfs-progsでも作ると警告出るし ドキュメントでも警告されててふつうに非推奨のままや http://mao.5ch.net/test/read.cgi/linux/1722312892/958
959: login:Penguin [sage] 2025/06/19(木) 12:07:41.63 ID:FZnGLgFp 昔みたterra stationは、xfsだったな。 RAIDもmdなんじゃ無いかな？ http://mao.5ch.net/test/read.cgi/linux/1722312892/959
960: login:Penguin [] 2025/06/19(木) 22:46:06.42 ID:/5HUQadQ 最近出てきた20TオーバのHDDでRAID5とか組んだらリビルドが終わらんだろうな http://mao.5ch.net/test/read.cgi/linux/1722312892/960
961: login:Penguin [] 2025/06/19(木) 23:25:44.44 ID:DYz6LZHt SSDならリビルドどれだけ速くなるんだろうか CPUが追いつかんか http://mao.5ch.net/test/read.cgi/linux/1722312892/961
962: login:Penguin [sage] 2025/06/20(金) 00:46:09.31 ID:qYS4FMam フラッシュメモリの特性として読込みに比べて書込みは桁違いに遅い 各種キャッシュで表面化しないようにしているけど 全面書込みではフラッシュメモリの特性が露骨に出てくる http://mao.5ch.net/test/read.cgi/linux/1722312892/962
963: login:Penguin [] 2025/06/20(金) 01:10:05.54 ID:eaZI5k8F SSDの書き込みが遅くなるのはフラッシュメモリのせいではなくMLCとかQLCのせいでは？ http://mao.5ch.net/test/read.cgi/linux/1722312892/963
964: login:Penguin [sage] 2025/06/20(金) 09:14:26.41 ID:kjXcySV2 SSD は書込寿命あるから不要な書き換えの多い RAID-5/6/Z1/Z2 あたりは非推奨みたいに言われてるんじゃなかったっけ？ http://mao.5ch.net/test/read.cgi/linux/1722312892/964
965: login:Penguin [] 2025/06/20(金) 11:18:26.58 ID:qYS4FMam 「不要な書き換え」が多い？ 具体的にはどのような書き換え？ 不要ならなぜ実装されているわけ？ http://mao.5ch.net/test/read.cgi/linux/1722312892/965
966: login:Penguin [sage] 2025/06/20(金) 11:56:16.09 ID:Uag62jWA 不要な書き換えについてはわからないけど、 RAIDとかファイルシステム直じゃない 抽象レイヤーを挟むと だいたいtrimは実行できなくなる感じ フラッシュメモリでは書き換えブロックが集中しやすくて 寿命の面では不利にはなりそう http://mao.5ch.net/test/read.cgi/linux/1722312892/966
967: login:Penguin [sage] 2025/06/20(金) 18:01:09.01 ID:kjXcySV2 >>965 すまない、この説の信奉者じゃないんで詳しくはないんだが... ランダムライトで4KiB書き換えた場合でもパリティは全書き換えだから、 チャンクサイズが64KiBだと4KiB+64KiB 書き換えが必要。 (4KiB 17回分) RAID-1 なら 4KiBx2 (2回分) で済む。 RAID-1 はシーケンシャルライトするだけで２倍書き込むから 書き込み回数でいうなら RAID-5 より多いじゃん、といえばそう なんだがドライブ１本あたりの書込回数って意味だと RAID-5 の方が多くなるとかなんとか。 ファイルシステムのメタデータはランダムアクセスなんで昔から メタデータについては RAID-5/6 は避けろとは言われているね。 とくに LustreFS や GPFS とか。 >>957 にもメタデータは RAID-1 にしろとある。 xfs も mkfs オプションでメタデータだけ別ブロックデバイスに 配置できるオプションが昔からあるが、そういえば使ったことないな。 http://mao.5ch.net/test/read.cgi/linux/1722312892/967
968: login:Penguin [] 2025/06/20(金) 20:34:29.47 ID:qYS4FMam ちゃんと元の論文なりきちんとした文献を読んだり理解していないようですね 下記wikiももっともらしく書いてありますが https://wiki.archlinux.jp/index.php/RAID RAID5の書込パフォーマンスが(n−1)Xで高速と書いてありますが大嘘ですよ 書込はストライプやストリップ境界と揃わない場合読込みが入り遅くなるのは常識 それをあえて書かないのは雑誌と同じで商業的にあえて触れていず不誠実です http://mao.5ch.net/test/read.cgi/linux/1722312892/968
969: login:Penguin [sage] 2025/06/20(金) 23:30:20.34 ID:kjXcySV2 >>968 んでそのストリップ境界でRMWする確率はどれくらいなんだい？ めったに起きないから(n-1)Xちかくで書き込むのを実測できるわけで。 論文なんてもはやトイレの紙にもならんもの読むんじゃなくて 一流企業のベンダーの資料に目を通したまえ。 http://mao.5ch.net/test/read.cgi/linux/1722312892/969
970: login:Penguin [] 2025/06/21(土) 00:20:30.96 ID:KlN9oYmI SSDはコントローラーのメーカーによってかなり動きが違うよね SSD全体を一般化して語るのはおかしいよ 1つのSSDで試しても他のメーカーでは違う結果が出るかもしれない http://mao.5ch.net/test/read.cgi/linux/1722312892/970
971: login:Penguin [] 2025/06/21(土) 08:41:29.45 ID:3iENlu5H >>963 どゆこと？ http://mao.5ch.net/test/read.cgi/linux/1722312892/971
972: login:Penguin [] 2025/06/21(土) 09:04:54.98 ID:KlN9oYmI SSDはHDDとは違ってKernelから認識しているデータ配置と実際の配置がまるで違うからな それを改善するためにZNS SSDとかいうのが出てきてるけど http://mao.5ch.net/test/read.cgi/linux/1722312892/972
973: login:Penguin [sage] 2025/06/21(土) 09:56:16.70 ID:p0nxy9BL btrfsでSSD RAID10してるけど2年くらい運用してるけど シリコンパワーとかいう半年で壊れるメーカーのせいで2度リビルドさせられた以外は特にトラブルなしだよ 安価なディスクを組み合わせて信頼性や性能を向上させるっていうRAIDの利点はSSDでは通用しないらしい http://mao.5ch.net/test/read.cgi/linux/1722312892/973
974: login:Penguin [sage] 2025/06/21(土) 12:11:27.31 ID:73DbppD8 読み書きの仕組みも HDD と結構違うぞ SSD の読み書きはページ単位(16KiB or 32KiB, 型番による)で Trim(消去) はブロック単位(512KiB など, 型番による) 書き込み回数を均す (Wear Leveling) 目的もあるので一旦書き込んだら上書きしない 1bit でも書き換えたページは別ページに書き直し 再利用するにはガーベージコレクションで使用中のページを別ブロックに追い出してブロック内の全ページを未使用状態にしてからブロック単位で Trim どうみてもデフラグ(略) まあ SMR (瓦書き込み: 1bit書き換えで最悪ハードディスク８回転ぐらい？させて書き込む(瓦を敷きなおす)必要がある) よりかはわかりやすいが http://mao.5ch.net/test/read.cgi/linux/1722312892/974
975: login:Penguin [sage] 2025/06/21(土) 12:15:57.44 ID:U4z6kL4u そもそもSSDはストライピング系のRAIDレベルで 速度向上させるまでもなく、 元々実用上十分なアクセス速度がある気がしなくもない… ベンチマークでの速度が目的なら何も言えないけど http://mao.5ch.net/test/read.cgi/linux/1722312892/975
976: login:Penguin [sage] 2025/06/21(土) 23:12:54.07 ID:EGQeHYc0 素人ですまんが fstrim って定期的に実行したほうがいいのは今も昔も変わってないよね？ http://mao.5ch.net/test/read.cgi/linux/1722312892/976
977: login:Penguin [sage] 2025/06/22(日) 02:57:18.54 ID:b/oVtT+X Trimの効果はファーム（メーカの方針）による 要するにモデルによって異なる まあ週一くらいで実行すればいいんじゃない http://mao.5ch.net/test/read.cgi/linux/1722312892/977
978: login:Penguin [sage] 2025/06/22(日) 05:05:30.19 ID:11SdqEm/ いまはsystemdに組み込まれたりして勝手に動いてるよ http://mao.5ch.net/test/read.cgi/linux/1722312892/978
979: login:Penguin [sage] 2025/06/22(日) 08:41:19.45 ID:A0LT32zn ファイルシステムからデバイスに対して未使用ブロックの報告をいつするか だからメーカの方針云々は間違いでは？ マウントオプションに discard を入れていれば fstrim 不要だけど rm する度に処理が走ってモタつくから週末あたりにまとめて fstrim しろって認識 http://mao.5ch.net/test/read.cgi/linux/1722312892/979
980: login:Penguin [sage] 2025/06/22(日) 09:50:55.11 ID:A0LT32zn 次スレ ファイルシステム総合スレ その21 ttps://mao.5ch.net/test/read.cgi/linux/1750553314/ http://mao.5ch.net/test/read.cgi/linux/1722312892/980
981: login:Penguin [sage] 2025/06/22(日) 09:53:10.66 ID:OD+5t1eX >>979 btrfsにはdiscard=asyncというオプションがあってな…… http://mao.5ch.net/test/read.cgi/linux/1722312892/981
982: login:Penguin [sage] 2025/06/22(日) 10:06:03.60 ID:A0LT32zn >>981 なんと。 Btrfs は discard でももたつかないんですね http://mao.5ch.net/test/read.cgi/linux/1722312892/982
983: 976 [sage] 2025/06/22(日) 13:39:40.31 ID:xmqJv8ux 愚かな質問に答えてくれてサンクス 週一で fstrim を実行するようにしておきます (systemd は使ってないので cron で) http://mao.5ch.net/test/read.cgi/linux/1722312892/983
984: login:Penguin [sage] 2025/06/22(日) 23:51:12.40 ID:B9faWsSI Apple Sparse Image Format(ASIF) というのもあるんだな。Linux/*BSD で使えないだろうけど。 http://mao.5ch.net/test/read.cgi/linux/1722312892/984
985: login:Penguin [] 2025/06/24(火) 04:21:12.07 ID:0xXwGjZF Appleがどれだけ優秀なファイルシステムを開発しようとサーバーとして使えないんだから意味ないわな http://mao.5ch.net/test/read.cgi/linux/1722312892/985
986: login:Penguin [sage] 2025/06/24(火) 06:13:53.77 ID:FuimOM5a mac miniをラックに大量に並べたデータセンターが増えてるようなニュースを一昔前に見たような http://mao.5ch.net/test/read.cgi/linux/1722312892/986
987: login:Penguin [] 2025/06/24(火) 06:45:55.92 ID:zRQ66erV それの用途はほとんど開発用だよ サーバーとしては使われていないと思う http://mao.5ch.net/test/read.cgi/linux/1722312892/987
988: login:Penguin [sage] 2025/06/24(火) 06:54:18.06 ID:cgRaSKJq CI/CDの機能提供に使うから開発用途の(実質)サーバーがほとんどだぞ http://mao.5ch.net/test/read.cgi/linux/1722312892/988
989: login:Penguin [sage] 2025/06/24(火) 12:16:49.05 ID:bxgNKxEs jenkinsサーバーとしてはmac miniは優秀だわ >>986 だが、m2 mac miniの登場で今までのmac mini筐体前提の収納ラックが 使えなくなったからなあ。旧mac mini向けdockも今投げ売り状態だし。 http://mao.5ch.net/test/read.cgi/linux/1722312892/989
990: login:Penguin [sage] 2025/06/24(火) 23:29:57.31 ID:VZSAuBH6 Jenkinsとか10年振りくらいに聞いたなぁ http://mao.5ch.net/test/read.cgi/linux/1722312892/990
991: login:Penguin [] 2025/06/25(水) 00:55:25.83 ID:6mW+O0oO ビルドって並行処理が効くからMacのCPUは効率悪いらしいけどな マルチコア性能低いから http://mao.5ch.net/test/read.cgi/linux/1722312892/991
992: login:Penguin [sage] 2025/06/25(水) 03:30:33.54 ID:x7IbPy0f 言うてiOSのアプリはそれ以外だとflutterくらいしかビルドする道がない http://mao.5ch.net/test/read.cgi/linux/1722312892/992
993: login:Penguin [sage] 2025/06/25(水) 05:22:08.71 ID:fazJZjgV ビルド(makeに限らない呼称?)やコンパイルの並行処理、マルチ処理って main.c io.c lib.c とか複数のコンパイルを並行処理のことをいっているのか lib.c のコンパイルで内部の関数毎にコンパイルを並行処理(こういうのある?)のようなのをいっているのか 両方含めた概念なのか http://mao.5ch.net/test/read.cgi/linux/1722312892/993
994: login:Penguin [sage] 2025/06/25(水) 12:45:50.70 ID:UO3T7u1B どっちでもいいだろ、アスペかよ http://mao.5ch.net/test/read.cgi/linux/1722312892/994
995: login:Penguin [sage] 2025/06/26(木) 04:44:48.67 ID:SHPlpET6 アスペは、滅びぬ。 http://mao.5ch.net/test/read.cgi/linux/1722312892/995
996: login:Penguin [sage] 2025/06/26(木) 04:46:20.00 ID:SHPlpET6 次スレ https://mao.5ch.net/test/read.cgi/linux/1750553314/l50 http://mao.5ch.net/test/read.cgi/linux/1722312892/996
997: login:Penguin [sage] 2025/06/26(木) 13:33:33.52 ID:SHPlpET6 EXT5というファイルシステムの話は、私は全然、見聞しませんが、EXT系はEXT4で完成形なのですかね。 ChatGPTに訊いても、XFSなどの話はありますけれど。 ZFSはメモリ大食いなのでおすすめしないとも、回答されましたが。 http://mao.5ch.net/test/read.cgi/linux/1722312892/997
998: login:Penguin [sage] 2025/06/26(木) 13:34:57.88 ID:SHPlpET6 ともあれ、話の続きは、次スレで・・・・。 http://mao.5ch.net/test/read.cgi/linux/1722312892/998
999: login:Penguin [sage] 2025/06/26(木) 13:35:35.45 ID:SHPlpET6 次スレ https://mao.5ch.net/test/read.cgi/linux/1750553314/l50 http://mao.5ch.net/test/read.cgi/linux/1722312892/999
1000: login:Penguin [sage] 2025/06/26(木) 13:35:55.70 ID:SHPlpET6 次スレ https://mao.5ch.net/test/read.cgi/linux/1750553314/l50 http://mao.5ch.net/test/read.cgi/linux/1722312892/1000
1001: 1001 [] ID:Thread このスレッドは１０００を超えました。 新しいスレッドを立ててください。 life time: 331日 0時間 21分 4秒 http://mao.5ch.net/test/read.cgi/linux/1722312892/1001
1002: 1002 [] ID:Thread 5ちゃんねるの運営はUPLIFT会員の皆さまに支えられています。 運営にご協力お願いいたします。 ─────────────────── 《UPLIFT会員の主な特典》 ★ 5ちゃんねる専用ブラウザからの広告除去 ★ 5ちゃんねるの過去ログを取得 ★ 書き込み規制の緩和 ─────────────────── 会員登録には個人情報は一切必要ありません。 4 USD/mon. から匿名でご購入いただけます。 ▼ UPLIFT会員登録はこちら ▼ https://uplift.5ch.net/ ▼ UPLIFTログインはこちら ▼ https://uplift.5ch.net/login http://mao.5ch.net/test/read.cgi/linux/1722312892/1002
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.027s