アカウント名:
パスワード:
今回の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 が「集荷の際にお荷物に損傷がなかったことを保証いたします」と言うようなものです。ユーザーが求めている信頼性とは少々異なります。
ブロックレベルのチェックサムは、ブロックが同一性を保っていることを保証するのみで、それが正しいブロックであるかどうか確認できません。UPS のたとえでいうと「荷物が途中で破損しなかったことを保証しますが、お客様の荷物かどうかは保証しません」ということになります。
リンク先の Oracle のサイト、詭弁ばっかりでジョークとしか言いようがない状況なんだが。
多くのストレージアレイでは、アレイの内部でデータとチェックサムを比較します。Dell|EMC PowerVault のレポートに、すばらしい解説つきで一般的な例が掲載されています。残念ながら、これではあまり役に立ちません。データとチェックサムが同じユニットに保存されるため、書き込み成功の誤報告 (前回書き込んだはずの内容がディスクに書き込まれていない) など、よくあるファームウェアのバグを検出できません。つまり、ディスクが古いデータを返しても、チェックサムは一致します。
HDD のファー
ZFSのコードにバグがあったらどうするんだ、に関してはその通りだと思う。
でもハードウェアやハードウェアのファームのバグの指摘に関しては的外れだと思う。ごくまれに起こる問題の話をしていていて、それを気にするユーザー向けだろう。すべてのハードウェアがバグ０だとか、従来のファイルシステムよりZFSの方がバグが多くて、ハードウェアのバグより深刻だと主張しているわけではないでしょ？
さすがにあんたの認識が甘いそれにレイヤー分けの考えが出来てない
ネットワークだってethernet fcs, ip heade checksum, tcp checksum と多数レイヤーに分けてチェックサムつけてるけど、これでも巨大ファイル転送時などにファイル壊れる可能性あるから iso イメージ等は sha1 等のチェックサムも同時に公開している。
ディスクのアクセスもレイヤに分けて考えるとEnd to endでファイルが壊れていないか確認するには End to End でのチェックサム値の転送が必要。
それは破損というより意図的な改ざんや偽物のチェックだね
いやいや、改竄対策はPGPシグネチャ等の電子署名が担当する。ハッシュ値は単なるファイル正常性の確認用。改竄対策もレイヤーが違う。
例えば TCP や TLS 等の通信路の暗号化等は、ファイルが正常に転送できることを意味しない。TLS が保証するのは通信路や通信端点（ソケット）同士の信頼性の確認であって、ファイルの正常性は確認していない。
HTTPSで公開しているファイルの完全性の確認はチェックサムが担当する。HTTPSで公開しているファイルの信頼性の証明は電子署名が担当する。# 電子署名は結果的にファイルの完全性の確認もできるが。
ソケットレベルでの完全性の対策：TLSファイルレベルでの完全性の対策：ファイルのチェックサム（チェックサム自体をファイルのデータとして含むのはアリ）情報レベルでの信頼性の対策：電子署名
それぞれレイヤーが違うTLS の通信が正常に完了していても、そのパケットデータを処理するプログラムが正常であるとは限らない。その対策がファイルレベルでの対策となる。PGPシグネチャなんかもverify時にKEYを同じサイトから持ってきたら意味ないからね。
通信経路上のノイズとか配布元のデータが壊れてたとか。何らかの理由で間違ったチェックサムを公開してしまうと正常なファイルが間違っていることになったり…
本来ハッシュは本体がなければ意味のないものだが、実際はファイルのキーとして独立して広く出回っているのだ元コメはこの事実を過小評価している
p2pファイル共有ソフトなどはアプリケーションで独自のファイルチェックをするから、転送後にさらにユーザーが再確認する必要性は限りなく低いしかしエッチなムービーを落としたはずが途中で千切れていた、猫映像だった、なんてことが多発したのでファイルのキーとしてハッシュを使うようになったのさ電子署名は鍵が必要だからこうはいかない
httpでファイルを落としたらそら壊れるだろうが、この話はレイヤーモデルの外なんだ
メモリが死んでるとファイルコピー時に化ける。案外珍しい事でもないし、負荷が高くなると低確率で起きるのも厄介。ファイルシステムにチェックサムがあるとそういう時に便利そう。
フラッシュメモリでデータが無警告で化けるのは普通にあるから怖い。大きなファイルだけ壊れるという恐ろしさ。だがフラッシュメモリのファイルシステムには通常選択肢が少ない。
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)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
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:何故 Win User は Copy-On-Write も チェックサム 無くても我慢できるん (スコア:0)
NASでは無意味なのは同意。
ただ、ZFS におけるエンド・ツー・エンドのデータ整合性 [oracle.com]を見ると、ReFSに意味がないということはなさそう。
たとえすべてのディスクが完璧に動作すると仮定できたとしても、入出力経路上のデータはまだ安全ではありません。コントローラのバグやDMA パリティーエラーなどがありえます。ユーザーにわかるのは、プラッタから読み取る瞬間までデータが完全だったというところまでです。データを小包に例えると、USP が「集荷の際にお荷物に損傷がなかったことを保証いたします」と言うようなものです。ユーザーが求めている信頼性とは少々異なります。
ブロックレベルのチェックサムは、ブロックが同一性を保っていることを保証するのみで、それが正しいブロックであるかどうか確認できません。UPS のたとえでいうと「荷物が途中で破損しなかったことを保証しますが、お客様の荷物かどうかは保証しません」ということになります。
Oracle のサイト、詭弁ばっかり (スコア:0)
リンク先の Oracle のサイト、詭弁ばっかりでジョークとしか言いようがない状況なんだが。
HDD のファー
Re: (スコア:0)
ZFSのコードにバグがあったらどうするんだ、に関してはその通りだと思う。
でもハードウェアやハードウェアのファームのバグの指摘に関しては的外れだと思う。
ごくまれに起こる問題の話をしていていて、それを気にするユーザー向けだろう。
すべてのハードウェアがバグ０だとか、従来のファイルシステムよりZFSの方がバグが多くて、ハードウェアのバグより深刻だと主張しているわけではないでしょ？
Re: (スコア:0)
さすがにあんたの認識が甘い
それにレイヤー分けの考えが出来てない
ネットワークだってethernet fcs, ip heade checksum, tcp checksum と
多数レイヤーに分けてチェックサムつけてるけど、これでも巨大ファイル
転送時などにファイル壊れる可能性あるから iso イメージ等は sha1 等の
チェックサムも同時に公開している。
ディスクのアクセスもレイヤに分けて考えるとEnd to endで
ファイルが壊れていないか確認するには End to End でのチェックサム値
の転送が必要。
Re: (スコア:0)
それは破損というより意図的な改ざんや偽物のチェックだね
Re:Oracle のサイト、詭弁ばっかり (スコア:1)
いやいや、改竄対策はPGPシグネチャ等の電子署名が担当する。
ハッシュ値は単なるファイル正常性の確認用。
改竄対策もレイヤーが違う。
例えば TCP や TLS 等の通信路の暗号化等は、ファイルが正常に転送できることを意味しない。
TLS が保証するのは通信路や通信端点（ソケット）同士の信頼性の確認であって、
ファイルの正常性は確認していない。
HTTPSで公開しているファイルの完全性の確認はチェックサムが担当する。
HTTPSで公開しているファイルの信頼性の証明は電子署名が担当する。
# 電子署名は結果的にファイルの完全性の確認もできるが。
ソケットレベルでの完全性の対策：TLS
ファイルレベルでの完全性の対策：ファイルのチェックサム（チェックサム自体をファイルのデータとして含むのはアリ）
情報レベルでの信頼性の対策：電子署名
それぞれレイヤーが違う
TLS の通信が正常に完了していても、そのパケットデータを処理するプログラムが正常であるとは限らない。その対策がファイルレベルでの対策となる。
PGPシグネチャなんかもverify時にKEYを同じサイトから持ってきたら意味ないからね。
Re: (スコア:0)
通信経路上のノイズとか配布元のデータが壊れてたとか。
何らかの理由で間違ったチェックサムを公開してしまうと正常なファイルが間違っていることになったり…
Re: (スコア:0)
本来ハッシュは本体がなければ意味のないものだが、実際はファイルのキーとして独立して広く出回っているのだ
元コメはこの事実を過小評価している
Re: (スコア:0)
p2pファイル共有ソフトなどはアプリケーションで独自のファイルチェックをするから、転送後にさらにユーザーが再確認する必要性は限りなく低い
しかしエッチなムービーを落としたはずが途中で千切れていた、猫映像だった、なんてことが多発したのでファイルのキーとしてハッシュを使うようになったのさ
電子署名は鍵が必要だからこうはいかない
httpでファイルを落としたらそら壊れるだろうが、この話はレイヤーモデルの外なんだ
Re: (スコア: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のベンダだからあなたの期待とレベルがあってないだけだよ。