アカウント名:
パスワード:
今回の1804ではなく前回1709でReFSの操作関連が削除されてるけど、不便で仕方が無い。そのくせファイルシステムのバージョンは勝手に上げやがるから1703に戻しても操作できないという。
スマホしか持っていない若い夫婦の家にも Synology NAS と呼ばれる機械が複数台あって驚いた聞いたところによると、スマホで撮った大量の動画とか写真とかを入れておくために使っているらしく普通の家には必ずあるらしい
こういった NAS と呼ばれる物体は、スマホしか持っていない初心者でも簡単に自宅サーバが建てられるもので、調べたところ、ファイルシステムは Synology も Netgear も Linux の Btrfs で、RAID に加えて、Copy-On-Write と チェックサムに対応している模様
Windows で NTFS しか使ったことない人は分からないだろうから簡単に説明すると、
Copy-On-Write:フ
安物のフラッシュメモリだと実際にはデータが破損しているのにコピーとか移動でエラーがでない「ビット腐敗」が良く起きるけどHDD でそんな問題有り得るの?WD Seagate TOSHIBA の3社ともディスクにチェックサム書き込んでて読み込み時にファームウェアレベルでチェックしているはず同じようなチェックサムの検証を、ファイルシステムレベルでもやったら冗長で時間の無駄なだけ
NASメーカーが無価値は無意味な機能で付加価値つけたようにアピールして消費者を騙しているんだよ
NASでは無意味なのは同意。ただ、 ZFS におけるエンド・ツー・エンドのデータ整合性 [oracle.com]を見ると、ReFSに意味がないということはなさそう。
たとえすべてのディスクが完璧に動作すると仮定できたとしても、入出力経路上のデータはまだ安全ではありません。コントローラのバグやDMA パリティーエラーなどがありえます。ユーザーにわかるのは、プラッタから読み取る瞬間までデータが完全だったというところまでです。データを小包に例えると、USP が「集荷の際にお荷物に損傷がなかったことを保証
メモリが死んでるとファイルコピー時に化ける。案外珍しい事でもないし、負荷が高くなると低確率で起きるのも厄介。ファイルシステムにチェックサムがあるとそういう時に便利そう。
フラッシュメモリでデータが無警告で化けるのは普通にあるから怖い。大きなファイルだけ壊れるという恐ろしさ。だがフラッシュメモリのファイルシステムには通常選択肢が少ない。
HDDならディスクの実容量の3%ぐらいがchecksum等に割り当てられていてファームウェアが検証しているからファイルシステムではchecksumを記録する必要も検証する必要もない。
フラッシュメモリには詳しくないけど、データが化けるとなると、フラッシュメモリには checksum が無いんだねmicroSD みたいに小型だとファームウェアレベルでchecksumの計算・記録・検証までやるのは難しいのだろうかなら、そういうフラッシュメモリ向けのファイルシステムでは、ファイルシステムレベルでchecksum入れるべきだな
> ディスクの実容量の3%ぐらいがchecksumチェックサムもまたディスクに保存するんだから、データとチェックサムの両方が化けると化けたデータを正当だとしたり、誤ったデータに「訂正」してしまう可能性があるね。
そういうことを気にする場合、対応としては起きにくくする仕組みを上か下のレイヤに重ねることになるね。(重ねても信頼性100%にはならない)
HDDからの経路の何処かで化けたりするから。
そうそう、メモリでホント普通に化けるよね。Oracleの詭弁でも何でも無いよ。
# それはともかく、Btrfsが信頼性あるって笑う所かな
メモリに関してはZFS使うような用途だとECC付メモリを使うんでないかな、と思う。まあ、そういうシステムでも、コントローラのメモリもECC付なのかとか、HDDのメモリはどうなんだとか気にはなるが。
Btrfs はファイルシステムレべルでデフラグできるんだけど、デフラグするとバグでデータ容量が2~3割平気で増えることがよくある
なんでもフラグメントするときに断片化したデータをコピーしながらデフラグする(COW方式)んだけどもとの断片化データへのリンクがメタデータからバグで消えないことがよくあるらしい
同様にデフラグするとスナップショットがハチャメチャになったり、スナップショットとのリンクが切れてディスク空き容量が大幅に減少することがあるひどいときにはデフラグしただけでTB単位で容量減ったりHDD空きが0になったりする
信頼性0のガラクタファイルシステムだわ
なるほどメモリの不具合で誤った書き込みデータがディスクに送られる可能性というのがあったか
OracleはHDDのファームウェアのバグとかより先に、もっと現実的なPCのメモリでデータが化ける可能性を書くべきだったな
商用UNIXのベンダだからあなたの期待とレベルがあってないだけだよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
ReFSは復活しないのか (スコア:0)
今回の1804ではなく前回1709でReFSの操作関連が削除されてるけど、不便で仕方が無い。
そのくせファイルシステムのバージョンは勝手に上げやがるから1703に戻しても操作できないという。
何故 Win User は Copy-On-Write も チェックサム 無くても我慢できるんだろ (スコア:0)
スマホしか持っていない若い夫婦の家にも Synology NAS と呼ばれる機械が複数台あって驚いた
聞いたところによると、スマホで撮った大量の動画とか写真とかを入れておくために使っているらしく
普通の家には必ずあるらしい
こういった NAS と呼ばれる物体は、スマホしか持っていない初心者でも簡単に自宅サーバが建てられるもので、
調べたところ、ファイルシステムは Synology も Netgear も Linux の Btrfs で、RAID に加えて、
Copy-On-Write と チェックサムに対応している模様
Windows で NTFS しか使ったことない人は分からないだろうから簡単に説明すると、
Copy-On-Write:
フ
Re: (スコア:0)
安物のフラッシュメモリだと実際にはデータが破損しているのにコピーとか移動でエラーがでない「ビット腐敗」が良く起きるけど
HDD でそんな問題有り得るの?
WD Seagate TOSHIBA の3社ともディスクにチェックサム書き込んでて読み込み時にファームウェアレベルでチェックしているはず
同じようなチェックサムの検証を、ファイルシステムレベルでもやったら冗長で時間の無駄なだけ
NASメーカーが無価値は無意味な機能で付加価値つけたようにアピールして消費者を騙しているんだよ
Re: (スコア:0)
NASでは無意味なのは同意。
ただ、 ZFS におけるエンド・ツー・エンドのデータ整合性 [oracle.com]を見ると、ReFSに意味がないということはなさそう。
たとえすべてのディスクが完璧に動作すると仮定できたとしても、入出力経路上のデータはまだ安全ではありません。コントローラのバグやDMA パリティーエラーなどがありえます。ユーザーにわかるのは、プラッタから読み取る瞬間までデータが完全だったというところまでです。データを小包に例えると、USP が「集荷の際にお荷物に損傷がなかったことを保証
Re:何故 Win User は Copy-On-Write も チェックサム 無くても我慢できるん (スコア:0)
メモリが死んでるとファイルコピー時に化ける。
案外珍しい事でもないし、負荷が高くなると低確率で起きるのも厄介。
ファイルシステムにチェックサムがあるとそういう時に便利そう。
フラッシュメモリでデータが無警告で化けるのは普通にあるから怖い。
大きなファイルだけ壊れるという恐ろしさ。
だがフラッシュメモリのファイルシステムには通常選択肢が少ない。
Re: (スコア:0)
HDDならディスクの実容量の3%ぐらいがchecksum等に割り当てられていてファームウェアが検証しているから
ファイルシステムではchecksumを記録する必要も検証する必要もない。
フラッシュメモリには詳しくないけど、データが化けるとなると、フラッシュメモリには checksum が無いんだね
microSD みたいに小型だとファームウェアレベルでchecksumの計算・記録・検証までやるのは難しいのだろうか
なら、そういうフラッシュメモリ向けのファイルシステムでは、ファイルシステムレベルでchecksum入れるべきだな
Re: (スコア:0)
> ディスクの実容量の3%ぐらいがchecksum
チェックサムもまたディスクに保存するんだから、データとチェックサムの両方が化けると化けたデータを正当だとしたり、誤ったデータに「訂正」してしまう可能性があるね。
そういうことを気にする場合、対応としては起きにくくする仕組みを上か下のレイヤに重ねることになるね。
(重ねても信頼性100%にはならない)
Re: (スコア:0)
HDDからの経路の何処かで化けたりするから。
Re: (スコア:0)
そうそう、メモリでホント普通に化けるよね。
Oracleの詭弁でも何でも無いよ。
# それはともかく、Btrfsが信頼性あるって笑う所かな
Re: (スコア:0)
メモリに関してはZFS使うような用途だとECC付メモリを使うんでないかな、と思う。
まあ、そういうシステムでも、コントローラのメモリもECC付なのかとか、HDDのメモリはどうなんだとか気にはなるが。
Btrfs は信頼性最悪 (スコア:0)
Btrfs はファイルシステムレべルでデフラグできるんだけど、
デフラグするとバグでデータ容量が2~3割平気で増えることがよくある
なんでもフラグメントするときに断片化したデータをコピーしながらデフラグする(COW方式)んだけど
もとの断片化データへのリンクがメタデータからバグで消えないことがよくあるらしい
同様にデフラグするとスナップショットがハチャメチャになったり、スナップショットとのリンクが切れてディスク空き容量が大幅に減少することがある
ひどいときにはデフラグしただけでTB単位で容量減ったりHDD空きが0になったりする
信頼性0のガラクタファイルシステムだわ
Re: (スコア:0)
なるほど
メモリの不具合で誤った書き込みデータがディスクに送られる可能性というのがあったか
OracleはHDDのファームウェアのバグとかより先に、もっと現実的なPCのメモリでデータが化ける可能性を書くべきだったな
Re: (スコア:0)
商用UNIXのベンダだからあなたの期待とレベルがあってないだけだよ。