[OSASK 934] Re: 続「OSASKのファイルシステム」

[n-hashi !Atmark! interlink.or.jp]

やっほぉ、<伊藤の旦那>
[2000年7月2日(日)]にもろた
【[OSASK 930] 続「OSASKのファイルシステム」】への返答っ! 。

伊藤>古い話の蒸し返しになりますが、ファイルシステムに関して質問です。

悪いけどツリーは分けるじょ。
＃分割しちゃったからねぇ。

伊藤>遅延書き込みについてだけど、書き込みがされる前の状態（データがメモリ上に
伊藤>ある時）で、マシンがクラッシュなり、電源が落ちたりすると、メモリ上のデー
伊藤>タは、消えてしまう様ですが、それってダサダサだと思いませんか？

うみゅ、そりはとっても情けない。

伊藤>という事で、ジャーナリングファイルシステムっていうのは使えないでしょうか？
伊藤>ジャーナリングファイルシステムってのは、ファイルシステムの更新履歴を保存
伊藤>しておいて、クラッシュした時に、更新履歴を元にクラッシュ直前の状態にファ
伊藤>イルシステムを戻せるファイルシステムだそうです。

CVSみたいなものかな？よくわかんないけど。

伊藤>あまり詳しくないので、識者の方捕捉お願いします。

私は当然識者ではないので捕捉(笑)はできません。

ということで私なりの答えを。

まず、遅延書き込みのうち、外部メディアに対してのものである場合は
その先行読み込みなりしているデータがあるのではないかと。
＃メディアのデータをHDDにプリロードしていたよね。
＃＃もちろんこれをHDDではなくメモリにロードするってのはやれるだろうし
＃＃もしそうした場合は、相応の処理（それこそ変更履歴をとってもいいだろうし）
＃＃が必要だろうけど。
なので、この場合は「データが消える」という最悪のパターンは無いハズ。

また、メモリ上のデータは、確かあくまでバッファしている範囲の代物
ということになるかと思いました。
なので、それを適宜３次バッファ（というか、要するにHDDやメディア自体かもしれないけど）
に書き戻しを行うようにしている・・・（んだよね）かと思った。

んで、要するにメディア自体か、そのプリロードのデータ自体が
残っていることで、「クラッシュ直前」のちょっと前なら確保できているのではないかと。

上記の例のようなシステムは、それこそUndo関連で利用できる代物なのではないかと。

しかし変更履歴ってのは実際必要な状況も多いので実装できればそれは幸い。
＃プログラムのリードミーとかも作りやすいでしょうし(笑)

どっちにしても上記で答えになるかな？
＃ならないかなぁ(;^^)

でわでわ

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/  氏名：もしかしたら橋　直行                                      _/
_/  E-mail:n-hashi !Atmark! interlink.or.jp,PXW06256 !Atmark! nifty.ne.jp             _/
_/_/_/_/_/_/_/_/_/_/_/_/_/-----平成12年07月02日(日曜日) PM08時29分_/_/