アカウント名:
パスワード:
今回の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メーカーが無価値は無意味な機能で付加価値つけたようにアピールして消費者を騙しているんだよ
WD Seagate TOSHIBA の3社ともディスクにチェックサム書き込んでて読み込み時にファームウェアレベルでチェックしているはず
読み込まない限り腐敗しているかどうかは分からないので、定期的に読み込んで腐敗してないかチェックするのがReFSの目的なのでは。
それが目的ならファイルシステムレベルのチェックサムはいらないと思うんだよね。チェックサムをつけると遅くなるので。
ただ読み込んでエラーがなければ捨てればいい。
NASでは無意味なのは同意。ただ、 ZFS におけるエンド・ツー・エンドのデータ整合性 [oracle.com]を見ると、ReFSに意味がないということはなさそう。
たとえすべてのディスクが完璧に動作すると仮定できたとしても、入出力経路上のデータはまだ安全ではありません。コントローラのバグやDMA パリティーエラーなどがありえます。ユーザーにわかるのは、プラッタから読み取る瞬間までデータが完全だったというところまでです。データを小包に例えると、USP が「集荷の際にお荷物に損傷がなかったことを保証
リンク先の 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のベンダだからあなたの期待とレベルがあってないだけだよ。
バグったコントローラがCPUの指示と違うデータをディスクに送っていたことないですか？私はあります。
個人的な経験としては、ここ10年ぐらいでパソコン使っててHDDでReadErrorは出ないけどデータが化けていたなんて経験は無いなHDDが壊れかけの時とかも読み取りエラーで読めないファイルが増えてく（ReadError発生でSMARTにも記録される）けど開くと化けるなんて現象にはお目にかかったことがない
フロッピーの時代にはよくあったけどね
> 私はあります。コントローラーがバグることもあるのか…確かにコントローラーがディスクに違うデータを送ったなら、ディスクはそのデータを基にチェックサムを生成して記録するから読み取り時にエラーは出ないということになってしまうねそういうときにはファイルシステムでのチェックサムは役に立つな
個人的な経験ではJPEGファイルが二度、破損したことがある。ただし、どこで破損したのかはわからない。破損を検知はできなかった。開いても絵としては壊れているファイルが読めて、読み込みエラーにはならない。
L2SW のメモリが故障してて特定パケットパターンでパケットが化けるとか過去にありました。
NASが一家に一台とは信じられない。まぁNTFSもそこそこ古いからなぁ。具体的にはぴんと来ないけどいろいろ古くなってはいるんだろう。ところでCopy On Writeの説明それであってる？ ジャーナリングファイルシステムならNTFSでもあるけど。チェックサムの保持もReFSのウリだけど、大ファイルの一部を書き換える毎にチェックサム取るとかパフォーマンス的に厳しそうだなぁ。チェックサムなんだからセクタ毎とか差分でやってるんだろうか。ただ実際ファイルコピーでハッシュが化けた記憶があるから多少は便利そうに思う。
Copy-On-Write:ファイルの内容を書き換えるときに、新しいデータを作って完成してからメタデータを書き換えるので、ファイル書き換え中にPCがクラッシュしてもデータが壊れない（書き換え前の状態のままになるだけ）
ところでCopy On Writeの説明それであってる
合っていない。COWって、データをコピーする場合、コピー元・コピー先に変更が発生するまで、実際にはコピーしない、って意味だよね。コピー元・コピー先に変更が無ければ、同じデータを参照できれば十分なので、データ二つ分の領域を使う無駄と、データコピーの手間が省ける仕組み。
FORK&EXECな世界での話
FORKしたときにメモリは同一内容でこぴーをつくってたVFORKでメモリはそのまま使う。どうせEXECで張り替えちゃうからちゃんと作ればコストが減る
MachOSでCopy-on-Write。FORK後読み込みやってる分にはそのまま。なんか書くとそのページをコピー
まあVMとファイル操作を統合してきた経過からファイルシステムの機能として表れてもおかしくないけど
machのmmap/vmとファイルシステムはmulticsに先祖返りしている
新訳 Copy On Write とか真 Copy On Write なのかと思ってググった。
synology の解説を見ると、スナップショットを保持するための技術らしいの。https://www.synology.com/ja-jp/dsm/Btrfs [synology.com]
一般的な解説はこちらじゃ。http://ascii.jp/elem/000/000/533/533454/index-2.html [ascii.jp]
確かに電源ブチギリしてもデータは壊れないが、この利点に関してはロギングとかジャーナリングの技術の利点として述べられることが多いかの。
>スマホしか持っていない若い夫婦の家にも Synology NAS と呼ばれる機械が複数台あって驚いたそんなのは極稀な例でしょ極稀な例、あるいは作り事を挙げて、長々と文章をupするなんて、惨めMSも需要が無いからやめたんでしょ。
> 普通の家には必ずあるらしい
それならSynologyはもっとでかい会社になっていていいだろうにｗｗｗ
Elecomと合併する前のLogitecの廉価NASが、「SynologyのOEMベースキットを買ってきてGUIの言語リソース翻訳だけして出したもの」だったらしいという話があったような。
> Copy-On-Write:
その説明はNTFSのジャーナリングのことでは？ここ [wikipedia.org]には別のことが書いてあるが
その説明はNTFSのジャーナリングのことでは？ ここ [wikipedia.org]には別のことが書いてあるが
Wikipedia の説明は広義の Copy-On-Writeだな
ファイルシステム業界では元コメの理解で正しい https://wiki.archlinux.jp/index.ph [archlinux.jp]
1989年には、HTFSが実装されOS/2に配備され、i80286でも動いていたのに
Windows3.0系95系にはFAT(VFAT,FAT32)しか与えられず…
2000年頃、Windows2000やXPに辿り着き、NTFSに出会うまでOSの異常停止で、ファイルシステムが崩壊する環境に甘んじてきた。
それがWindows Userだと思っていますし最近のWindows Userは文句を言い過ぎだと思います :-)
HPFS (High Performance File System)？
Btrfsもコンシューマレベルに使えるレベルで安定稼働可能になったのは3年前くらいだったような?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
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)
WD Seagate TOSHIBA の3社ともディスクにチェックサム書き込んでて読み込み時にファームウェアレベルでチェックしているはず
読み込まない限り腐敗しているかどうかは分からないので、定期的に読み込んで腐敗してないかチェックするのがReFSの目的なのでは。
Re: (スコア:0)
それが目的ならファイルシステムレベルのチェックサムはいらないと思うんだよね。
チェックサムをつけると遅くなるので。
ただ読み込んでエラーがなければ捨てればいい。
Re: (スコア:0)
NASでは無意味なのは同意。
ただ、 ZFS におけるエンド・ツー・エンドのデータ整合性 [oracle.com]を見ると、ReFSに意味がないということはなさそう。
たとえすべてのディスクが完璧に動作すると仮定できたとしても、入出力経路上のデータはまだ安全ではありません。コントローラのバグやDMA パリティーエラーなどがありえます。ユーザーにわかるのは、プラッタから読み取る瞬間までデータが完全だったというところまでです。データを小包に例えると、USP が「集荷の際にお荷物に損傷がなかったことを保証
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のベンダだからあなたの期待とレベルがあってないだけだよ。
Re: (スコア:0)
バグったコントローラがCPUの指示と違うデータをディスクに送っていたことないですか？
私はあります。
Re: (スコア:0)
個人的な経験としては、ここ10年ぐらいでパソコン使っててHDDでReadErrorは出ないけどデータが化けていたなんて経験は無いな
HDDが壊れかけの時とかも読み取りエラーで読めないファイルが増えてく（ReadError発生でSMARTにも記録される）けど開くと化けるなんて現象にはお目にかかったことがない
フロッピーの時代にはよくあったけどね
> 私はあります。
コントローラーがバグることもあるのか…
確かにコントローラーがディスクに違うデータを送ったなら、ディスクはそのデータを基にチェックサムを生成して記録するから読み取り時にエラーは出ないということになってしまうね
そういうときにはファイルシステムでのチェックサムは役に立つな
Re: (スコア:0)
個人的な経験ではJPEGファイルが二度、破損したことがある。
ただし、どこで破損したのかはわからない。
破損を検知はできなかった。
開いても絵としては壊れているファイルが読めて、読み込みエラーにはならない。
Re: (スコア:0)
L2SW のメモリが故障してて特定パケットパターンでパケットが化けるとか過去にありました。
Re: (スコア:0)
NASが一家に一台とは信じられない。
まぁNTFSもそこそこ古いからなぁ。具体的にはぴんと来ないけどいろいろ古くなってはいるんだろう。
ところでCopy On Writeの説明それであってる？ ジャーナリングファイルシステムならNTFSでもあるけど。
チェックサムの保持もReFSのウリだけど、大ファイルの一部を書き換える毎にチェックサム取るとかパフォーマンス的に厳しそうだなぁ。チェックサムなんだからセクタ毎とか差分でやってるんだろうか。
ただ実際ファイルコピーでハッシュが化けた記憶があるから多少は便利そうに思う。
Re: (スコア:0)
Re:何故 Win User は Copy-On-Write も チェックサム 無くても我慢できるん (スコア:1)
Copy-On-Write:
ファイルの内容を書き換えるときに、新しいデータを作って完成してからメタデータを書き換えるので、
ファイル書き換え中にPCがクラッシュしてもデータが壊れない（書き換え前の状態のままになるだけ）
ところでCopy On Writeの説明それであってる
合っていない。
COWって、データをコピーする場合、コピー元・コピー先に変更が発生するまで、実際にはコピーしない、って意味だよね。
コピー元・コピー先に変更が無ければ、同じデータを参照できれば十分なので、データ二つ分の領域を使う無駄と、データコピーの手間が省ける仕組み。
Copy-On-Write って元々は仮想メモリの用語では？ (スコア:0)
FORK&EXECな世界での話
FORKしたときにメモリは同一内容でこぴーをつくってた
VFORKでメモリはそのまま使う。
どうせEXECで張り替えちゃうからちゃんと作ればコストが減る
MachOSでCopy-on-Write。FORK後読み込みやってる分にはそのまま。
なんか書くとそのページをコピー
まあVMとファイル操作を統合してきた経過からファイルシステムの機能として表れても
おかしくないけど
Re: (スコア:0)
machのmmap/vmとファイルシステムはmulticsに先祖返りしている
Re: (スコア:0)
新訳 Copy On Write とか真 Copy On Write なのかと思ってググった。
synology の解説を見ると、スナップショットを保持するための技術らしいの。
https://www.synology.com/ja-jp/dsm/Btrfs [synology.com]
一般的な解説はこちらじゃ。
http://ascii.jp/elem/000/000/533/533454/index-2.html [ascii.jp]
確かに電源ブチギリしてもデータは壊れないが、この利点に関しては
ロギングとかジャーナリングの技術の利点として述べられることが多いかの。
Re: (スコア:0)
>スマホしか持っていない若い夫婦の家にも Synology NAS と呼ばれる機械が複数台あって驚いた
そんなのは極稀な例でしょ
極稀な例、あるいは作り事を挙げて、長々と文章をupするなんて、惨め
MSも需要が無いからやめたんでしょ。
Re: (スコア:0)
> 普通の家には必ずあるらしい
それならSynologyはもっとでかい会社になっていていいだろうにｗｗｗ
Re: (スコア:0)
Elecomと合併する前のLogitecの廉価NASが、「SynologyのOEMベースキットを買ってきてGUIの言語リソース翻訳だけして出したもの」だったらしいという話があったような。
Re: (スコア:0)
> Copy-On-Write:
その説明はNTFSのジャーナリングのことでは？
ここ [wikipedia.org]には別のことが書いてあるが
Re: (スコア:0)
> Copy-On-Write:
その説明はNTFSのジャーナリングのことでは？
ここ [wikipedia.org]には別のことが書いてあるが
Wikipedia の説明は広義の Copy-On-Writeだな
ファイルシステム業界では元コメの理解で正しい
https://wiki.archlinux.jp/index.ph [archlinux.jp]
Re: (スコア:0)
1989年には、HTFSが実装されOS/2に配備され、i80286でも動いていたのに
Windows3.0系95系にはFAT(VFAT,FAT32)しか与えられず…
2000年頃、Windows2000やXPに辿り着き、NTFSに出会うまで
OSの異常停止で、ファイルシステムが崩壊する環境に甘んじてきた。
それがWindows Userだと思っていますし
最近のWindows Userは文句を言い過ぎだと思います :-)
Re: (スコア:0)
HPFS (High Performance File System)？
Re: (スコア:0)
Btrfsもコンシューマレベルに使えるレベルで安定稼働可能になったのは3年前くらいだったような?