アカウント名:
パスワード:
書き込み時（寿命などを検出したときだけでも？）に空きブロックと代替して書き込み頻度を分散するという仕組みがうまく動けば、とは前から言われていたと思います。しかし、今のファイルシステムではディスク側に未使用になりましたと通知する機能がないので、一時的であってもディスクに書き込んでしまうと、SSD 側ではそこを代替領域として使用できないことになります。例えばフォーマット時にゼロクリアしてしまうとかです。
SSDドライブの耐用年数を増やすセクタ破棄リクエスト [atmarkit.co.jp]
つまり、製品購入当初は、一度も書き込みされていない書き込み分散用に使える未使用ブロックが大量にあるが、年月を経るにつれどんどんその未使用ブロックが減っていき、書き込みがあまり分散されなくなってしまうということです。 実は、ATAプロトコルにはdiscardリクエストというプロトコル拡張があり、これによりブロックを未使用に戻すことができます。しかし、メーカが提供する専用フォーマットソフト以外ではほとんど使われていませんでした。 ここに目を付けて、ファイルシステムのファイル消去とともに、フラッシュメモリコントローラに「当該ファイルのデータが存在するブロックを未使用ブロックとして扱っても構わない」と教えてあげることができれば、フラッシュメモリの耐久年数が大幅に上がるのではないか……というのが今回のパッチのミソです。
つまり、製品購入当初は、一度も書き込みされていない書き込み分散用に使える未使用ブロックが大量にあるが、年月を経るにつれどんどんその未使用ブロックが減っていき、書き込みがあまり分散されなくなってしまうということです。
実は、ATAプロトコルにはdiscardリクエストというプロトコル拡張があり、これによりブロックを未使用に戻すことができます。しかし、メーカが提供する専用フォーマットソフト以外ではほとんど使われていませんでした。
ここに目を付けて、ファイルシステムのファイル消去とともに、フラッシュメモリコントローラに「当該ファイルのデータが存在するブロックを未使用ブロックとして扱っても構わない」と教えてあげることができれば、フラッシュメモリの耐久年数が大幅に上がるのではないか……というのが今回のパッチのミソです。
なるほど、と思いました。この方法であれば、既存のファイルシステムにそれほど大きな変更をしないでも SSD をずっと有効に活用できそうに思います。
あとは寿命が近いブロックを不良セクタとして扱うなどして実質的な空き領域の量を把握できるような補助的なツールなどがあると良いかもしれません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
ファイルシステムによる最適化？ (スコア:1, 興味深い)
現在のファイルシステム（そこではext2/3/4が話題に上ってましたが）は
HDDの仕組みを考慮した、線形アクセスを旨とする設計になっているので
これをそのままSSDに使用してもSSDを活かし切れないらしいです。
将来、ファイルシステムが一新されることで
ある時点でSSDの寿命がポンと増える…ということはないんでしょうか。
Re: (スコア:1)
SSD側で何らかのバッファリングした方がいいと思います。
Re:ファイルシステムによる最適化？ (スコア:1)
書き込み時（寿命などを検出したときだけでも？）に空きブロックと代替して書き込み頻度を分散するという仕組みがうまく動けば、とは前から言われていたと思います。しかし、今のファイルシステムではディスク側に未使用になりましたと通知する機能がないので、一時的であってもディスクに書き込んでしまうと、SSD 側ではそこを代替領域として使用できないことになります。例えばフォーマット時にゼロクリアしてしまうとかです。
SSDドライブの耐用年数を増やすセクタ破棄リクエスト [atmarkit.co.jp]
なるほど、と思いました。この方法であれば、既存のファイルシステムにそれほど大きな変更をしないでも SSD をずっと有効に活用できそうに思います。
あとは寿命が近いブロックを不良セクタとして扱うなどして実質的な空き領域の量を把握できるような補助的なツールなどがあると良いかもしれません。
鍵はデフラグ？ (スコア:0)
もちろんファイルを積極的にかき混ぜるということが目的となるのでSSD専用のデフラグということになるでしょうが...
とりあえず言いだしっぺの法則を発動して
ここで命名者と開発者募集くらいは行っとくか
Re:鍵はデフラグ？ (スコア:3, 参考になる)
あまり更新されないブロックは、今後も更新されない可能性が高いと考えられますから、
適当なタイミングで更新頻度の高いブロックに移動させてしまえば良いのです。
これで更新回数の多いブロックの劣化防止と、更新回数の少ないブロックの解放が同時に行えます。
セクタ番号と物理的なブロックをマッピングする仕組みさえ挟めば、
このようなブロックの移動は自由に行えます。ていうか普通にやってると思いますよ、今どきは。
こういうのは OS がやっても最大公約数的で大雑把な管理しかできないでしょうし、
一方でフラッシュメモリも時代や規模によって特性や理想的な管理方法も変化すると思いますから、
デバイス側のコントローラーに任せてしまう方が良いと思いますね。
OS はそれこそ「セクタの解放をデバイスに知らせる」程度にしておいて。
Re: (スコア:0)
参考になりました。
ところで、普通のUSBメモリもやってるのでしょうか？
Re:鍵はデフラグ？ (スコア:1, 参考になる)
そこでAHCI上に専用プロトコルを載せて、組み込みでやってるような低レベル制御までやろうとしてるのがNVMHCI [intel.com]。対抗規格も出てくるかもしれませんが、OSが直にセルの管理までするのはこういう規格がサポートされてからじゃないですかね。