確かにそこは分離して欲しいですね…。
HDD死んだときフラッシュだけ生きてても微妙な気がしますが、
逆は使えないと悲しすぎますしw

あとHDDと一体化した場合、デフラグ処理とかは自動的に回避されるんですかねぇ。
SSDだと考慮されそうという記事があったんですが、今回は大丈夫なんでしょうか?

 

[SSDへの期待と課題]から抜粋
　HDDと同じ感覚でデフラグなどのプログラムを定期的に実行すると、あっという間に書き換え可能回数の上限に達してしまう可能性がある。
　そこでMicrosoftでは、接続されているストレージデバイスがHDDかSSDであるかをIDで識別可能にし、SSDの場合はHDD用のデフラグプログラムを利用しないようにすることを考えている。ハードウェア的にも、1台のSSDにSLCとMLCを組み合わせ、ファイル管理領域のように頻繁に書き換えられる部分をSLCに割り当てる、DRAMキャッシュを併用することで書き込みを最適化する(ただし不揮発性など一部メリットを失う)など、さまざまな対策が検討されている。
http://pc.watch.impress.co.jp/docs/2007/0521/hot487.htm [impress.co.jp]

>ページサイズ (4 KB) ごとに分けて頻度が高い部分のみをキャッシュするはずで、ファイル全体の大きさは関係ないんじゃないかと。

キャッシュは、ファイル単位じゃないんですね・・・
タレコミに使用頻度の高いファイルをキャッシュって書かれてて思ったことだったんで。

だとすればVistaの機能なんて必要なんでしょうか？
MFUのキャッシュなら、HDDだけで済むような気がするんですが・・・

と、思って他のコメント見てたらハイブリッドディスク用の
ATAコマンドを利用して、キャッシュの制御をする、とありますね。
つまり、VistaからはまさにReadyBoostのUSBメモリの代わりとして使うようなイメージなんですかね。

# 単純なMFU/MRUよりは賢いロジックでキャッシュが出来るということかな？
# でも、ReadyBoost用メモリだとするとサイズが小さいように・・・うーん・・

アンチノイマン？

>>昔：CPU-DRAM-FDD
>昔：CPU-DRAM-コンパクトカセットテープ
昔：CPU-DRAM-カードの束

急いで運んでいるときに限ってケースをひっくり返してそれはもうエラいことに。
それ以降、束の側面をマーカーで斜めに線引きするやり方を身につけました。

mmap ってのは別にLinux特有の機能じゃないですが…それはさておき、
UN*X系OSでのmmapとかWindowsのCreateFileMapping などはは、アプリケーション側が明示的に指示しないとファイルがメモリ空間上に現れませんが、
「単一レベル記憶」な環境では、OSなどがmmap的な処理を裏で行ってくれますので、アプリケーション側が意識する必要がありません。
その上で書かれたプログラムでは、「ファイルアクセス」のためのコードは、単なる「メモリアクセス」になります。

アプリケーションから見ると、一見 mmap のみ提供されて file descriptor による通常のファイル入出力(read/write)はできなくなってる感じですが
「単一レベル記憶」では、外部記憶装置のデータが全て主記憶空間上の個別のアドレスに配置されるのに対し、
mmapなどは「mapしなおすと、同じアドレスを別のファイルを指すことがある(アドレス→データが一意じゃない)」あたりは単一レベル記憶的じゃないです。