ミドルウェアの変更だけでSSDの書き込み速度を大幅に向上させる技術 37
ストーリー by hylom
平均的にはどれくらい向上するのかが気になるが 部門より
平均的にはどれくらい向上するのかが気になるが 部門より
中央大学の竹内健教授ら研究グループが、ミドルウェアの修正だけで書き込み速度や消費電力、書き換え可能回数などを大幅に改善できるという技術を発表した（日経新聞）。
NANDフラッシュメモリでは、書き込み時に実行される断片化されたデータの再配置および無効な領域のブロック単位での消去処理によって書き込み速度が大幅に低下する。ミドルウェアでの処理でこれを回避することで、書き込み速度を向上できるという。
具体的にはデータの書き込み先ブロックを制御するアルゴリズムを改良することで断片化やブロック単位での消去処理を減らすとのことで、シミュレーションでは書き込み速度を最大4倍にでき、また消費エネルギーや書き換え回数も減ったという。この技術はハードウェアの変更なしに利用できるため、現行のSSDでもすぐに利用できるという。
話は聞かせてもらった。HDDは絶滅する！ (スコア:5, おもしろおかしい)
ΩΩ<な、NANDぁってー
Re:話は聞かせてもらった。HDDは絶滅する！ (スコア:2, おもしろおかしい)
Ω ΩΩ早く大事なデータをNORの箱舟に乗せないと！
あるある (スコア:3, おもしろおかしい)
「凄い技術だなと思ったら自分の記事だった。」
https://twitter.com/kentakeuchi2003/status/469904540553068545 [twitter.com]
自分が出したものが何かで紹介されても、それを自分のものだとすぐ分からず、「おお、私と同じ発想の人が居た！」とか喜んでしまったりするんですよねぇ。
Re: (スコア:0)
たまに、自分のブログとかがはてブやグノシーに乗ると思いますね。お、俺の好きそうな話の記事だって。
Re: (スコア:0)
Googleで検索してて,数年前にも同じ事を調べてたんだな…とブログやTwitterを見て気がついたり
次期SSDから順次対応するので (スコア:2)
早くしたけりゃ新しいの買ってください
現行のSSDでも対応できるけどそれやると売れなくなるのでやりません
Re: (スコア:0)
キミ、陰謀論とか好きそうだよね。
Re: (スコア:0)
陰謀っていうか企業側からしたら本音しょう。
現行のものにやったら買い替え需要が減るのは目に見えてるし。
Re: (スコア:0)
何の話題でも被害妄想ベースの陰謀論で悟り顔したがる人いますよね
まあ高二病ともいいますが
Re: (スコア:0)
Re: (スコア:0)
まあ、SSDは、より大容量な物が出れば買い換える余地があるから、
既存の製品のパッチを出しても別に良いんじゃ無い？
サポートすれば、次も自社商品を選んでもらえる可能性が上がりそうだし。
Re: (スコア:0)
新しいのはもっと早くなります。
Re: (スコア:0)
>早くしたけりゃ新しいの買ってください
うーん
3~4年前と違い、ここ1年半くらいを見ると、
SSDのモデルチェンジや容量増加が緩やかになりつつあるので
必ずしも「新しいのを買え」とは言えなくなってきている気がする。
IntelもCrucialも1世代前のモデルを併売してる。
(在庫がたくさん有るだけなのか、それとも固定需要があって再生産しているのか、それは不明)
でも (スコア: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
Re: (スコア:0)
むしろメーカーがファームウェアレベルで取り組んでるのと同種のものじゃないの？
Re:でも (スコア:2)
現行製品のファームウェアを比較用に使えるとは思えないし。
Re: (スコア:0)
リスクが高すぎてほとんど無理では…
これから開発する製品に採用するならともかく
# そもそもメーカーもあれこれ工夫はしているだろうし、既に似たようなことをやっていたりして、変わる機種もあれば変わらない機種もあるのでは
Re: (スコア:0)
寿命短くなりません？
Re:でも (スコア:1)
本来ガベコレ対象になるものを先取りして保存に使うのだから、書き込み回数は増えないというか、むしろ減るのでは。
書き込み回数が寿命に直結しますから、寿命を延ばせる可能性はある。
ただし、ブロック単位で寿命が短くなる場所はあるかも。
-- To be sincere...
読んだ感じだと (スコア:0)
単純にドライバを変えればいけるんじゃないの？
Re: (スコア:0)
メモリキャッシュを使うので技術的には少し違うけど、Linuxのdm-writeboostとか。
http://akiradeveloper.hatenadiary.com/ [hatenadiary.com]
現行のSSDでもすぐに利用できるという (スコア:0)
今動かしてるSSDを、
ファームのアップデートみたいな感じで、
中のデータに何の影響もなく利用できるようになるのだろうか。
Re:現行のSSDでもすぐに利用できるという (スコア:1)
買い替え促進のためにアップデータは提供されません
買い替え促進 (スコア:0)
ファームウェアやドライバの更新もしないメーカーなんてねぇ
Re: (スコア:0)
うちにあるプラスドライバとマイナスドライバ、もう何十年も更新されてません
Re:買い替え促進 (スコア:1)
そいつはもうだいぶ昔からstableです
Re: (スコア:0)
currentなドライバもありまっせ、検電ドライバ
Re: (スコア:0)
rigidなやつ…
Re:まるでどこぞのOSみたいな商法ですな (スコア:0)
脅迫ウィルスと大差ないというか