アカウント名:
パスワード:
「HDDがコマンドを順に実行するとは限らない」 という情報が出て来てます。これは、、、 (1) 本当ですか？
推測なんですが、本当なんじゃないでしょうかね。たとえば SCSI-2 だと command queuing があって reorder が許されてたと思います。本当にそういうことをするデバイス(ディスクドライブ)があるかどうかは知りませんが、あってもおかしくはないのではないかと(物理セクタに不良があった場合など、reorder とかしてるかも)。
(2) LFSやJFSの設計に影響しますか？
本当なら影響するんだけれど、個々のデバイスの内部での reorder は機種やメーカーによって
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
一体どれ使えばいいの? (スコア:0)
Re:一体どれ使えばいいの? (スコア:3, 参考になる)
ちょっとlinuxに関して手厳しい意見に見えるかも
しれませんが、とにかく、これだけファイルシステムに
関して詳しく解説しているところって滅多にないんじゃ
ないかと思います。是非、御一読を。
Re:一体どれ使えばいいの? (スコア:0)
次のような記述があります。
> 図 4.4(d) ではじめて inode が更新される。
> inode は一般に HDD の sector サイズよりも小さいので、
> この更新は all or nothing で実行される。
> 従って、inode が「破損」する可能性は考えなくて良い。
これは嘘です。
大抵のハードディスクでは、
セクタへの書き込み中に電源が落ちると、
そのセクタのデータが壊れる可能性があります。
このことは各社
Re:一体どれ使えばいいの? (スコア:1)
> 2つ目は、 Storage はある単位での write リクエストに対して、
> 完全実行か無実行になることだ。 もっと分かりやすく言えば、
> SCSI IO request の単位でもいいし、 IDE のコマンドの単位でもいいし、
> sector 単位の書き込みでもいいから、 とにかく「この命令を実行し始めたら、
> これだけは最後までやり遂げる」 という基本単位を保証してもらわ
> なくてはいけない、と言うことだ。 一般には、これは Sector 単位で
>保証されていて、 ある Sector を上書きし始めたら、その Sector
> の書き込みに関しては HDD 側が保証するのが一般的だ。
指摘されてる件は、現実的ではあっても、上述の前提条件を満たして
いない場合ですよね。これを仮定しないと「いわゆるジャーナル
ファイルシステム以外全部ダメ」の結論しか出ない。
それ以外の優劣を論じるためにクリティカルセクションの大きさを
基準にしている。
と、読んだのですが違ってますか？
＃現実の電源断でセクタが壊れる可能性自体は認めますよ。もちろん。
Re:一体どれ使えばいいの? (スコア:0)
現実的でないモデルにもとづいて
> それ以外の優劣を論じ
ることにどれだけ意味があるのでしょうか。
むしろ私は、
> これを仮定しないと「いわゆるジャーナル
> ファイルシステム以外全部ダメ」の結論しか出ない
から、都合のよい前提条件を仮定したのではないか、
と、読んだのですが違ってますか？
そもそも、元の資料 [iij4u.or.jp]の
> このRobust なファイルシステムの実装には3つの前提がある。
Re:一体どれ使えばいいの? (スコア:1)
断罪に見えたので反応しただけです。私自身が有識者ではありません。
>むしろ私は、
(略)
>から、都合のよい前提条件を仮定したのではないか、
>と、読んだのですが違ってますか？
それらが優れているのは認めながらも、それで終りにしたくなかったん
じゃないかと勝手に想像してます。
>そもそも、元の資料 [iij4u.or.jp]の
>> このRobust なファイルシステムの実装には3つの前提がある。
>の部分がおかしいです。
こっちの方は、あの文書の弁護や代弁しようとは思いません。
＃ただ、あれは３年ぐらいは前の文書ですよね。多分。
代わりに、私の疑問を提出しときます。
別コメント [srad.jp]で「HDDがコマンドを順に実行するとは限らない」
という情報が出て来てます。これは、、、
(1) 本当ですか？
(2) LFSやJFSの設計に影響しますか？
これらがどちらもyesだとしても、LFSやJFSが無意味なわけではないですよね？
あの文書とsoftupdateも、当時は(FreeBSDでは現在も)同程度に意味が
あった(ある)のだと思います。
＃ほとんど歴史文書だと分かんないことが問題。
Re:一体どれ使えばいいの? (スコア:0)
推測なんですが、本当なんじゃないでしょうかね。たとえば SCSI-2 だと command queuing があって reorder が許されてたと思います。本当にそういうことをするデバイス(ディスクドライブ)があるかどうかは知りませんが、あってもおかしくはないのではないかと(物理セクタに不良があった場合など、reorder とかしてるかも)。
本当なら影響するんだけれど、個々のデバイスの内部での reorder は機種やメーカーによって
Re:一体どれ使えばいいの? (スコア:1)
FSとHDDとでそれぞれ現状を仮定して、別々に設計の最適化を行っているのが
うまく噛みあってないみたいですね。両者が集まってモデル作りをしないと
いけないのでしょう。
メタデータの書き込みと一般のデータの書き込みを分離して、メタデータ側は
reorderしないことぐらいが最低限の必須要件なんですかね？
Re:一体どれ使えばいいの? (スコア:0)
「2つの書き込みがあったときに どちらが先に書き込まれるかを指定する手段があること」
だけです。そして現行のハードディスクはこの条件を守っています。
この条件が満たされれば、ファイルシステムはログに対するトランザクションの開始と終了を確実に行えま
Re:一体どれ使えばいいの? (スコア:1)
「重要なのは、トランザクションに続いてデータが書き込まれるという
順序で、それぞれの中での書き込み順は問題ではない。完了したか、
しなかったかが分かればよい」
ということでしょうか？
どうも、私はメタデータとトランザクションとを混同していたようです。
ども、長々とありがとうございました。
＃ところで、この話題って２回目ですか？
＃教えてもらってもすぐ忘れる奴＞わし。
Re:一体どれ使えばいいの? (スコア:0)
LFS や JFS に関していえば、そうです。
> ＃ところで、この話題って２回目ですか？
> ＃教えてもらってもすぐ忘れる奴＞わし。
はやく前回のトランザクションがコミットされてるかたしかめて！