ファイルシステム総合スレその20

[過去ﾛｸﾞ] ファイルシステム総合スレその20 (1002ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

845: 2024/10/10(木)23:56 ID:WGFMDZfJ(1/2)調 AAS
属性を保持したまま内容を一気に入れ替えるのは、今ならcopy_file_rangeがある

846: 2024/10/10(木)23:57 ID:WGFMDZfJ(2/2)調 AAS
で、こいつはCoWファイルシステムじゃないと本当に内容をコピーするので効率が悪い

847(1): 2024/10/11(金)07:39 ID:/6otHtpl(1)調 AAS
停電を予測してスナップショットを撮る機能が追加されるとかしないとかいう話は聞いたことがない

848: 2024/10/11(金)14:12 ID:mj4qPltc(1)調 AAS
そこでNILFSですよ

849: 2024/10/11(金)16:05 ID:P6k6G+uZ(1)調 AAS
Nipple?

850: 2024/10/11(金)22:21 ID:5hgxSCWq(1)調 AAS
>>842
renameでのinode置き換えならunlinkはいらんし、user拡張属性なら転記するだけでいいけど何気にしてるか分からん

851: 2024/10/12(土)00:50 ID:oiiqPhbz(1)調 AAS
>>847
10年近く前にそんなファイルシステムを作ってたな
紆余曲折でプロジェクトはポシャったけど

852: 2024/11/01(金)23:30 ID:fOkGcY4d(1)調 AAS
openZFSの新しいDedupについて

https://despairlabs.com/blog/posts/2024-10-27-openzfs-dedup-is-good-dont-use-it/

853: 2024/11/02(土)00:19 ID:VFPv/92F(1)調 AAS
タイトルからして良いのか使うななのか。言いたい事は何故か分かった

854: 2024/11/02(土)02:38 ID:QhRsNAf7(1)調 AAS
かなり改善されたけど一般的な使い方ではdedupを使う価値は無いとのこと

855(1): 警備員[Lv.21] 2024/11/21(木)20:13 ID:84+fZx8I(1)調 AAS
https://www.phoronix.com/news/Bcachefs-Uncertain-Kernel-Issue

よりによってLinusが行動規範違反持ち出してワロス

856: 2024/11/21(木)20:17 ID:irrhUSYn(1)調 AAS
Linus先生の精神修養の効果はどれぐらい持続したんだろうか

857: 2024/11/21(木)21:25 ID:IaoA0KbF(1)調 AAS
カーネルは何千人も開発に関わってるプロジェクトだからな
問題があるメンテナは受け入れられないよ

858: 2024/11/22(金)10:35 ID:NLeFvCAZ(1)調 AAS
kent君が結構アレなので……

859: 警備員[Lv.22] 2024/11/22(金)11:21 ID:LsZKWQ6U(1)調 AAS
https://www.phoronix.com/news/ReiserFS-Deleted-Linux-6.13

> ReiserFS Has Been Deleted From The Linux Kernel

ついに……
それにしてもFS開発者ってキチガイ多くね？

860: 2024/11/23(土)10:44 ID:Suo8i6kX(1)調 AAS
>>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みたいな文章がアウトってこと?

861: 警備員[Lv.1][新芽] 01/25(土)07:58 ID:woka93X8(1)調 AAS
zfsはせっかく良いファイルシステムなににちょっと勿体無いね

862: 01/26(日)03:10 ID:gS4o5s0d(1)調 AAS
zfsはエンプラ用途すぎて中小企業や一般ユーザにはとても合わないと思うが

863: 01/26(日)13:22 ID:Wag9xtbO(1)調 AAS
むしろ中小企業向けだろZFSは
でかい企業は分散ファイルシステム使うだろうし

864: 01/26(日)19:09 ID:zsOq4jRe(1)調 AAS
中小企業は
1. 重複排除、スナップショット、圧縮が安定して使え
2. Active Directory の連携し CAL も不要、
3. 故障時ハードベンダーにお任せで社内技術者による属人化を無視可能
な中身がWindows IoT の NAS 製品買うでしょ。

エンタープライズも並列ファイルシステムの Lustre の中身
(ldiskfs(ext4) か ZFS が選択可能) として位ではないかな。
実績面で疑問が残る Lustre ZFS をまともに運用出来る人員を確保
できる組織が存在するかは疑問だが。

865: 警備員[Lv.5][新芽] 01/27(月)11:47 ID:GOJgDLEA(1)調 AAS
zfsよりbtrfsの方が勢いあるしな

866: 01/27(月)12:03 ID:K25csgYz(1/2)調 AAS
NAS企業同士がexfat対btrfsで論争してなかったっけ、どうなったんだろ

867: 01/27(月)14:04 ID:xG3E2DwG(1/2)調 AAS
ext4の間違いでは？
exfatなんて対抗にならないだろ

868: 01/27(月)14:26 ID:K25csgYz(2/2)調 AAS
あ、素手間違えてたごめん
もちろんext4
思い出そうとして今ぐぐったらQNAP、ReadyNAS、Synologyあたりが論争してたみたい

869: 01/27(月)19:01 ID:K2hOghs1(1)調 AAS
ext4ファイルシステム破損問題を思い出した
https://atmarkit.itmedia.co.jp/flinux/rensai/watch2009/watch11a.html

870: 01/27(月)19:30 ID:xG3E2DwG(2/2)調 AAS
なんでそんな古い記事を
つい2年くらい前にext4が壊れたことあっただろうに
アプデですぐ治ったけど

871: 01/27(月)21:32 ID:thSG6MDn(1)調 AAS
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

872: 01/27(月)21:40 ID:/u6c3b6/(1)調 AAS
QNAP君がBtrfsにグチグチ言ってるのは、こんなFS流行ったら非エンタープライズNASの商売上がったりだからかと思ったら煽り合う相手がいたのかw

873: 警備員[Lv.1][新芽] 01/30(木)00:46 ID:Mp6Sx01c(1)調 AAS
対抗馬のBcachefsはまだ実績なさすぎて使い物になるのはいつになる事やら

874: 02/01(土)15:37 ID:sek/ETxb(1)調 AAS
openzfsがファイル名の1023バイト長に対応した
今までlinuxのまともなfsの中ではgpfsぐらいしか無かったから
windowsとのinteropを気にしてる人にとっては朗報なんじゃ

875(2): 02/02(日)12:11 ID:MUcsqS+0(1)調 AAS
stdio.h で定義されているからコンパイル済のソフトじゃ使えんじゃん、
て思って調べてみたら結構前(CentOS6/手近にあった最古)でも FILENAME_MAX
は 4096 だったわ。

876: 02/06(木)22:00 ID:mnoX/Jvp(1)調 AAS
ビットロット対応のFSふえてくれ
winもmacも含めて

877: 02/06(木)22:22 ID:CxpOZANU(1)調 AAS
ファイルシステム作る人、圧倒的に性格悪い説
zfs, ReiserFS, Bcachefs

878: 02/07(金)07:57 ID:kPy0cZmS(1)調 AAS
なんで？

879(1): 02/07(金)21:46 ID:0He1QcLs(1)調 AAS
>>875
それはフルパスでは？
NAME_MAXがファイル名の規定のはず

880: 02/10(月)15:37 ID:ZXNyKkDA(1)調 AAS
ext4の人は性格悪くないから単なる偶然だな
zfsは知らん、reiserfsは妻殺し、bcachefsは手順も踏まず自己主張ばかりうるさい

881: 02/10(月)17:21 ID:qkuqaI2M(1)調 AAS
zfs やOpen Solaris はCDDLで、GPLというかLinuxに成果を取られないようにイジワルしているとしか...

第6回 Debian 会議で Cooper は、Solaris カーネルを書いた技術者らが OpenSolaris が GPL 非互換となるよう要求したと述べている。「Mozilla が選ばれた理由のひとつとして、GPL非互換だからというのがある。

Common Development and Distribution License（CDDL）
https://ja.m.wikipedia.org/wiki/Common_Development_and_Distribution_License

882: 02/10(月)17:28 ID:5o8c5ISg(1)調 AAS
コピーレフトなのにGPL非互換なライセンスか、こんなのあるんだな

883: 02/10(月)18:13 ID:ojBXykV6(1)調 AAS
ワイは作者さんの開発成果に世話になってるから感謝してる、性格はしらん

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
知らんけど仕様の制限より先にメモリサイズの制限のほうが先に来るだろう

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".
https://en.m.wikipedia.org/wiki/Bcachefs

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
https://www.phoronix.com/review/linux-611-filesystems

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は根本的に解決してないし
多分これからしばらくも解決されません

https://www.phoronix.com/news/Linux-6.2-Btrfs-EXT4
https://www.reddit.com/r/btrfs/comments/127zmsx/what_do_you_think_about_the_kernel_62_btrfs/

そもそも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
リビルドによる冗長性ってなに？

914(1): 06/15(日)17:08 ID:6DNeCkGf(1)調 AAS
RAIDはアレイが破損したらリビルドかける前に
全データバックアップしろが通説だと思った

バックアップする空きストレージがないとか
そもそもバックアップがないなら
そもそもその運用がおかしい…
(捨ててもいいデータだけとか観て消し録画は除く)

915(1): 06/15(日)17:27 ID:xQc9M6ba(1/2)調 AAS
なんでRAIDやりたがるのか意味不明
バックアップの工夫をそれなりにやって
ダウンタイムやデータ損失期間を減らすための最終仕上げだよね
それとも広告であるネット記事を見て導入が大半?

916(1): 06/15(日)17:35 ID:aJl0W6/T(2/2)調 AAS
>>913
https://e-words.jp/w/%E5%86%97%E9%95%B7%E6%80%A7.html
https://www.buffalo.jp/topics/trouble/detail/recovery_0005.html
RAIDの文脈で「冗長性」ってのは
RAID構成内に故障したハードウェアが出てもデータの完全性が損なわれない事
「リビルド」ってのはもっぱらその故障したハードウェアを入れ替えて元の冗長性を持つ構成に再構築することを指す
この説明でわかんないんだったら俺にはうまく説明出来ねえ
「リビルドできる冗長性に～」の方がもっと正確な言い回しだったといえばそれはそうなので
わかってて言ってたら単に俺の日本語が下手でごめんだな

>>914-915
本当にクリティカルなデータを扱うなら
定時記録的なオフラインバックアップが常に別にあって
「退避」や「サルベージ」をやる必要すらほぼ無いのが理想だし本当なら当然
もちろん実現にはハードウェアも運用もコストが相応に要るので難しくなるけどね
冗長性が無い状態での改めての読み出しは
結局リビルドとやってる事は似てて当然ながらもし残りのハードウェアが故障すれば(読み出せなくなった分は)完全にパーなんで
これはどちらかというと現実的な次善策

それこそbtrfsならスナップショットとsend/receiveをうまく使えば
オフラインバックアップ用の場所にも高速に増分バックアップ出来るよ

917(1): 06/15(日)18:37 ID:YrR/Ub7i(1)調 AAS
btrfsのsnapは呆気ないほど簡単にファイルの先祖返りが長期も短期も可能で、
WinがやっているVolume Shadow Copyの上位互換って印象で、個人的にはとても好き。

でも、バックアップは別途必要かなって思っている。神経質なだけかもだけれど、データって一番大事だから増分・差分だけじゃなく、本体も自分は保持するようにしている。

918(1): 06/15(日)21:04 ID:YaPsiovj(3/3)調 AAS
>>916
冗長性ってリビルドのためではなくサービスを止めないためのものでは？
リビルドしなくても冗長性は重要だよ

919: 06/15(日)21:36 ID:xQc9M6ba(2/2)調 AAS
びっくりしたのはRAIDでリビルド機能が無いと言われたとき
そりゃまぁデータ消えないけどそのまま運用とか狂人だろうに
おーこわいこわい

920: 06/15(日)21:39 ID:nO4JLxoc(1)調 AAS
>>917
btrfsなら親になるスナップショットを指定して増分モードでsend/receive出来るから
外部にも、
つまり「バックアップ」もスナップショット構造を維持しながら
書き込みは増分だけで済むよって話なんだ

例えばオリジナル上でSnapperで毎日撮ってて06-15→06-16→06-17とかあるとして
同一の06-15が送受信するストレージ上に同時にあれば
それを親に指定して06-16は差分だけ転送で済む
そして06-16が同時にあればそれを親にして06-17は差分だけで……で継ぎ足し出来るわけさ
https://btrfs.readthedocs.io/en/latest/Send-receive.html

>>918
だから「RAIDの文脈で」って前置きして例のURLまで出してるでしょ
「RAIDの文脈で言う『冗長性』は主にはグループのうちn台が故障してもデータの完全性を保ち、そこからリビルドが出来る事」であって
例えば何かしらサーバーとして運用されてる物ならその全体の可用性として
一般的な語句で言う「冗長性」が望ましいというのは事実だしあんたは何も間違ってないけど
それはファイルシステムとデータだけに留まらない話

「たとえリビルドをしなくても全体の冗長性が重要」なんてのはそりゃ当然だけど
ファイルシステム総合スレなんだから
第一にファイルシステムとそれに関連するデータ保存の目的の文脈で話をしてるに決まってるじゃん

921: 06/16(月)02:21 ID:upbk3sl3(1/2)調 AAS
リビルドは最初からあまり期待しない。
HDDがいかれたときは他のHDDも寿命間近で、リビルド中にお釈迦になった経験がある。

raidを使う利点はコントローラから警告音が盛大に出ることとバックアップの時間が稼げること。

ソフトウェアraidの利点も時間稼ぎかな。

922: 06/16(月)03:30 ID:V26EfEYC(1)調 AAS
業務用ストレージならスクラブが走るからリビルドあんま失敗しないけどね
最近は別の不具合でボリュームが全損するケースがちらほらある
ストレージも最近高いくせに品質悪いな

923: 06/16(月)05:44 ID:zRTb+SAk(1/2)調 AAS
RAID1ならリビルドするけどRAID5や6はやらないかなあ
時間かかりすぎるよ

924: 06/16(月)07:30 ID:7sPaAkac(1)調 AAS
> バックアップの時間が稼げる
これが大事だと思う

925: 06/16(月)07:45 ID:upbk3sl3(2/2)調 AAS
時間稼ぎだからデータ逃がせる環境ならraid5で十分だよ。

926(1): 06/16(月)12:57 ID:7WvLU0an(1)調 AAS
リビルドせずにバックアップ取得
ならRAID不要の環境だし普段からバックアップしとけよ
どれだけ踊らされているのか

927: 06/16(月)16:46 ID:zRTb+SAk(2/2)調 AAS
>>926
どういうこと？
リアルタイムバックアップしろってこと？

928: 06/17(火)03:11 ID:G5q8UCPD(1/8)調 AAS
バックアップは毎日取るものでしょ
差分だけなら時間もわずかなので

なんでRAID縮退時にバックアップを取る前提なの?
普段からとってないの?

929: 06/17(火)04:39 ID:Z0BbVoQp(1)調 AAS
日に一度のバックアップならやっぱりRAID必要やん
なぜそれでRAID不要になるのか

930: 875 06/17(火)09:00 ID:lZRqBMI7(1/4)調 AAS
「壊れた瞬間に使えなくなる」のか、「まだ使える/処理を継続
できる」のか、はかなり重要なファクターだと思うが？
流石にバックアップあればRAID不要は極論。

ハードウェアRAIDはスクラブやらSMART監視で部分的な故障まで
監視しているからリビルド失敗はない。
失敗した場合でもRAIDカード交換させたら治ったこともあるから
似たようなことがったらカード交換も検討するといいよ。

LVM,ファイルシステム,デバイスドライバーによるソフトウェアRAID
やらフェイクRAIDも「４～５年ごとにハードを買い替える」ことが
守れてば大丈夫だと思うけどねぇ。

931: 06/17(火)09:22 ID:G5q8UCPD(2/8)調 AAS
優先度について述べているだけ
バックアップを定期的に取らないのにRAID導入しているのが見受けられる

932: 06/17(火)10:22 ID:lZRqBMI7(2/4)調 AAS
バックアップに対する現場の意識が足りない、という意味で言いたいのは
わからんでもないが、データロストと(RAIDなし環境における)業務/納期
遅延のそれぞれリスクを発生確率を交えて考えると、やはりその意見には
賛同できないよ。

933(2): 06/17(火)10:29 ID:YcGRWNVI(1/4)調 AAS
一切の故障がなくてもURE(回復不可能な読み取りエラー)は確率的に起きるのでまず前提が間違ってる
もちろん製品のグレードによりけりで
エンタープライズ用HDDなら限りなく低い確率、具体的には10^15ビットに1回になるぐらいの品質で製造されてるけど
どのHDDにも起き得るし一般的な民生用だと10^14ビットに1回程度で更に確率が上がる

TB単位のストレージでRAID5が現実的じゃないってのは
読み取るサイズが増える分だけURE=リビルド失敗の可能性が高まるから
8TBだと仮定して民生用だと約60%、エンタープライズ用でも約6％ぐらいの確率で失敗する可能性がある

んでRAID1なら片肺でも読み出し出来るし
リトライも容易だけどRAID5じゃそうはいかねー事が多いからな

934(1): 06/17(火)11:49 ID:fFPZtW+I(1/2)調 AAS
RAID5,6は理論上の速度や容量効率は利点だけど、
データチャンク、XORパリティで細切れブロック配置したり複雑で
ディスク上のビット単位でのデータ信頼性という意味では
物理ヘッドガチャガチャするHDDではRAID0よりキツそう
(そんなに詳しくないから想像だけど)

実際には様々なレイヤーのパリティやビット訂正で
エラー回復してるんだろうけど、自分が使ってる
RAID1(Btrfs)でさえ3週に1度スクラブかけると
半分ぐらいの確率でエラー訂正しましたのログが残ってるのだわ

935: 06/17(火)12:00 ID:G5q8UCPD(3/8)調 AAS
URE(回復不可能な読み取りエラー)
というのは媒体mediumエラーでしょ?
HDD/SSDコントローラは生きていて
特定LBA(LogicalBlockAddress)でエラーがでる
局所的ブロック、媒体エラーだよね
HDD/SSD内部でソフトウェア的エラーの可能性はあるけど
カーネルから見たらハードウェアエラー(==故障)だよ
これ範

936: 06/17(火)12:02 ID:G5q8UCPD(4/8)調 AAS
あとRAID使っているわりには
ファンや電源の冗長化してないよね
これらも故障したら交換するまで停止でしょ

937: 06/17(火)12:12 ID:fFPZtW+I(2/2)調 AAS
>>933
言われてみればそうだなあ…
HDDだけダウンタイムなしまたは交換時間オンリーを想定してても、
HDDの故障率と比べて電源やファンとかM/B等パーツが
それより壊れないかと言うとうーんって思う…

自分の環境はファンは予備があってすぐ交換できるし、
電源はACアダプターのマザボ運用してるのでちょっとマシ
(ノート用のよくある19VでOK)

938(1): 06/17(火)12:57 ID:G5q8UCPD(5/8)調 AAS
>>933
は事実と異なる内容を記述している
あるHDD/SSDでURE(回復不可能な読み取りエラー)が出たら
RAIDレベルによらず全HDD/SSD稼働中なら他のHDD/SSDのデータから復元できる
(要は1台故障と同じ(切り離して故障にするかは別問題でコントローラの設計))
HDD/SSD故障があるのならRAIDレベルによらず多重故障でデータ復元できない
RAID6は2点故障でも復元できるけど

939(1): 06/17(火)13:27 ID:lZRqBMI7(3/4)調 AAS
現場的には6%はかなり盛り過ぎだと感じるわ。
RAID のチャンクサイズ考慮して計算されてないか、
スクラブとかSMART監視とかない前提？

940: 06/17(火)13:37 ID:1K0szjjx(1)調 AAS
>>938
だから「リビルドがUREで失敗する確率は決して低くない」という話だって言ってるじゃん
冗長性のあるRAIDレベルで通常稼働時に単一の障害が訂正出来るのは当たり前じゃねーかw

>>939
あくまで「リビルド中にUREに遭遇する確率」をカタログスペックから単純計算(概算)した数字の話なので
もちろん実際の障害の可能性はもう少し前後し得るよ

改めて補足しとくけどUREはSMARTとかからわかる形で
明確に「故障」せずとも読み取り時に偶発的に起きる確率的現象で
だから市販製品のデータシートにもちゃんと書いてあるんだ(Non-recoverable errors per bits readの項とかその辺り)
もちろん業務用途ならHDD/SSDにしろRAIDカードにしろソフトウェアRAIDにしろ
ずっと上等で堅牢な構成を採用してる事が多いから
破滅的な結果に至る確率はぐっと低いよ
あくまで典型的には個人がRAID5やるシナリオだと致命的になりがちって話ね

https://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
https://www.seagate.com/files/www-content/product-content/hdd-fam/seagate-archive-hdd/en-us/docs/archive-hdd-dS1834-3-1411us.pdf

941: 06/17(火)13:51 ID:G5q8UCPD(6/8)調 AAS
5分停止したら何億とか会社消滅ならRAIDでサービス継続は分かる

でも個人用途ではHDD故障して機能のバックアップで十分
データ書き戻しで半日くらい止まっても大丈夫
これらが大半
RAID不要だろって話
webや雑誌記事でのせられて使っているだけでしょ?

942: 06/17(火)13:52 ID:G5q8UCPD(7/8)調 AAS
昨日のバックアップデータで許容ね

943: 06/17(火)14:22 ID:89jEObby(1)調 AAS
linux板って個人と企業を混合して話をするからエスパー力を必要とされるね

944: 06/17(火)16:34 ID:TRstYWTQ(1)調 AAS
>>934
3週間間隔でエラー補正かかる、は流石にディスクの方を疑おうよ…

上下前次 1-新書関写板覧索設栞歴

あと 58 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.025s