SMR HDDはRAID用ではないと主張していきたい (大容量ランダムアクセス磁気ディスクとしては悪くない)

正直なところ、SMRに対応したファイルシステムまで必要なのか?という疑問があるが、僕はSMRに対応したOSとやらにSMRに対応したしたファイルシステムの要素まで持っていてほしいと期待しているような気がした mstdn.kuriuzu.tk/@kuriuzu/1040

実際SSDはOSにTrimの対応や、ファイルシステムのクラスタ境界を削除ページ境界に合わせる形で既存のファイルシステムを使いまわしているわけじゃん? SMR特有の制御ができれば既存のファイルシステムで十分な気がするんですよ (ある意味これはディスクマネージとホストマネージの合わせ技か)

@hadsn 既存ファイルシステムの小改造で対応可能だと思う。ランダム書込を並び替えずにシーケンシャルに書き込むとか、断片化解消が無負荷時にバックグラウンドで自動で走るとか、そんな感じになるのかなあ。

フォロー

@kuriuzu ランダム書き込みを並べ替えないのはSMRディスクに対するホストマネージ機能だと思うし、断片化解消が無負荷時にバックグラウンドで自動で走るというのもやはりホストマネージ機能のうちだと思う (ファイルシステム側の機能ではないと思う)

@hadsn OS,ファイルシステムという用語の定義が互いに違う気がしてきた。私は"Trimの対応や、ファイルシステムのクラスタ境界を削除ページ境界に合わせる"もファイルシステムの機能だと思ってる。

@kuriuzu NTFSを例にとるけど、ファイルを削除したときにファイルをディスクから抹消することは、NTFSでは必須としてなかったわけじゃん? そこでSSDに対応するために、Winsows側では当該のボリュームがSSD上にあることを認識してTrimコマンドを実行しているわけだから、OS側での対応という認識になるんですよ。クラスタ境界にしても、ファイルシステムとしてはそのような仕様を定めてない (AT互換機のMBR形式ではシリンダ境界規定があったが) 以上は、OSが (ファイルテーブルとしての) ファイルシステムを作るときの1オプションに過ぎないと思うわけで

@hadsn 「ファイルシステム」という用語が、「ディスクに記録するときの記録方式の規格」か「特定の記録方式に対応するための実装(ソフトウェア一式)」のどっちなのか、という。私は後者も含めてファイルシステムと呼んでいた。

@hadsn SMRの話に戻ると、規格としてのファイルシステムに手を加える必要はなく、(オプションとして)OSの実装だけ修正すれば良い、という意見はその通りだと思う

ログインして会話に参加
:realtek:

思考の /dev/null