アカウント名:
パスワード:
どれだけのメーカーが出荷済の製品に対応してくれるんだろうか
今回の話はミドルウェアが対応すれば良いって話だから、ファイルシステム等の対応で行けるんじゃないの？
リンク先の説明見る限りでは、SSDのファームとファイルシステムの共同作業で実現するような話のようだからこの記事での「ミドルウエアだけで完結」というのは（生NANDの構造は従来のままで）駆動方法を変えるだけで＝ミドルウエアを変えるだけで完結、と言っているのだと思われますNANDチップ屋の観点では、SSDのファームもOSのファイルシステムもひっくるめて「ミドルウエア」と呼ぶのが普通なのかもしれません
何度読み返してもファイルシステムは関係なくセクタ単位の話な気がしますが。前回のデータベースアプリの際の話と混じってませんか？今回のはSSD内部(ファーム)で完結するGC最適化に一般化したお話だと思います。
元記事をみずに類推。フラッシュメモリの物理セクタの一部を書き換える場合、あくまで物理セクタ単位での管理としている場合、セクタをRAMにバックアップし、セクタをイレース、RAM上で書き換えて、セクタ全体に書き込む、という処理にしてた。でも、セクタの一部に未使用領域があるなら、そこには書き込まない様にする。これでその未使用領域にデータ書き込みしたい時は、「RAMに退避してセクタイレースして・・・」って手順を採らずに直接未使用領域に書き込める。
そのために、物理セクタより微小な論理サブセクタで管理するか、バイト単位の可変長ブロックで管理するかはファームウェアの実装次第。論理サブセクタをファイルシステムのセクタサイズにすると管理が簡単かな？セクタ管理の記憶領域だけでもFeRAMとかに記憶させる様にすれば更に高速化・高寿命化が図れるかも。
ページの中をどのファイルで埋めていくかという話みたいだから、ファイルシステムからのライト先セクタ番号の指示が肝になるんだろう。
そして、OSが考えているページが実際のフラッシュメモリ上でどこに配置されるかは、SSDのファームウェアが勝手に決めて、ウェアレベリングでさらに再配置されるから、OSから見て矛盾がないようにSSD側で適当にやってくれ、で済むんじゃないかな？（ウェアレベリングで移動しても中身のセクタ同士の位置関係は変わらないところが重要）
つまり、OSのファイルシステム（WindowsならNTFSのドライバ）はSSD用に変更（最適化）が必要、SSDのファームは無変更ということでは？
# リンク先の日経の「新しい空白のページにデータを書き込むのではなく～」の部分が意味不明だが。# 直前の図も訳分からんし# Prop.の右側中段のnew dataは青矢印の移動前と移動後のどっちで書いたものだ？
いや、新規のAPIが必要って話。
DBMSだと、データのファイル内での位置をアプリ側で調整出来るから、データ更新時に消去済みセクタになる場所に置く様にすると速いよねってだけ。
でも、事前に空いてるセクタ（＝或るファイルの何処か）を知る為には、SSDのファームからファイルシステム（RAWじゃ無い場合）まで巻き込んで、何かの新機構が必要になる。
つ trim
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
でも (スコア:0)
どれだけのメーカーが出荷済の製品に対応してくれるんだろうか
Re:でも (スコア:2)
今回の話はミドルウェアが対応すれば良いって話だから、
ファイルシステム等の対応で行けるんじゃないの？
Re:でも (スコア:3, 興味深い)
リンク先の説明見る限りでは、SSDのファームとファイルシステムの共同作業で実現するような話のよう
だからこの記事での「ミドルウエアだけで完結」というのは（生NANDの構造は従来のままで）
駆動方法を変えるだけで＝ミドルウエアを変えるだけで完結、と言っているのだと思われます
NANDチップ屋の観点では、SSDのファームもOSのファイルシステムもひっくるめて
「ミドルウエア」と呼ぶのが普通なのかもしれません
Re:でも (スコア:1)
何度読み返してもファイルシステムは関係なくセクタ単位の話な気がしますが。
前回のデータベースアプリの際の話と混じってませんか？
今回のはSSD内部(ファーム)で完結するGC最適化に一般化したお話だと思います。
Re: (スコア:0)
元記事をみずに類推。
フラッシュメモリの物理セクタの一部を書き換える場合、あくまで物理セクタ単位での管理としている場合、セクタをRAMにバックアップし、セクタをイレース、RAM上で書き換えて、セクタ全体に書き込む、という処理にしてた。
でも、セクタの一部に未使用領域があるなら、そこには書き込まない様にする。これでその未使用領域にデータ書き込みしたい時は、「RAMに退避してセクタイレースして・・・」って手順を採らずに直接未使用領域に書き込める。
そのために、物理セクタより微小な論理サブセクタで管理するか、バイト単位の可変長ブロックで管理するかはファームウェアの実装次第。論理サブセクタをファイルシステムのセクタサイズにすると管理が簡単かな？
セクタ管理の記憶領域だけでもFeRAMとかに記憶させる様にすれば更に高速化・高寿命化が図れるかも。
Re:でも (スコア:1)
ページの中をどのファイルで埋めていくかという話みたいだから、ファイルシステムからのライト先セクタ番号の
指示が肝になるんだろう。
そして、OSが考えているページが実際のフラッシュメモリ上でどこに配置されるかは、
SSDのファームウェアが勝手に決めて、ウェアレベリングでさらに再配置されるから、
OSから見て矛盾がないようにSSD側で適当にやってくれ、で済むんじゃないかな？
（ウェアレベリングで移動しても中身のセクタ同士の位置関係は変わらないところが重要）
つまり、OSのファイルシステム（WindowsならNTFSのドライバ）はSSD用に変更（最適化）が必要、
SSDのファームは無変更ということでは？
# リンク先の日経の「新しい空白のページにデータを書き込むのではなく～」の部分が意味不明だが。
# 直前の図も訳分からんし
# Prop.の右側中段のnew dataは青矢印の移動前と移動後のどっちで書いたものだ？
要SSD用API (スコア:2)
いや、新規のAPIが必要って話。
DBMSだと、データのファイル内での位置をアプリ側で調整出来るから、データ更新時に消去済みセクタになる場所に置く様にすると速いよねってだけ。
でも、事前に空いてるセクタ（＝或るファイルの何処か）を知る為には、SSDのファームからファイルシステム（RAWじゃ無い場合）まで巻き込んで、何かの新機構が必要になる。
-- Buy It When You Found It --
Re: (スコア:0)
つ trim