アカウント名:
パスワード:
普通、書き換え回数の平均化を行なうように分散書き込みを行なうコントローラーが入っている
実際の所どこがのいいの？
そんな風になるためには*有効なファイル*が書かれているブロックと書かれていないブロックをSSDのコントローラが区別しなければならないわけで
chip内のflash memoryの制御とそれらを集合させてSSDとして利用するという話はレベルが違うんです。
一見関係ありそうで関係ない話を始める
HDDの書き込み回数は理論的に無限ですが、Flashは有限ですので本質的にモデルが異なります。
*有効なファイル*が書かれているブロックと書かれていないブロックをSSDのコントローラが区別しなければならない
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
SSDの書き換え耐久性に疑問 (スコア:5, 参考になる)
SSDのメーカーに故障の解析をさせたら、装置の動作ログがしょっちゅう書き込まれていたために、その部分のメモリセルの書き換え寿命によるクラッシュだと診断された。
ハードディスクなら2年～4年は生きているのに。
最近のSSDやUSBメモリはその問題をクリアしているのだろうか。
その部分？ (スコア:1, 参考になる)
Re:その部分？ (スコア:5, 興味深い)
仮に入ってたとして、全体の容量の10%ぐらい余分に記録できるようになっていたとしても、その上に使用率90%のファイルシステムを組むと、全体としては20%をぐるぐる回しているだけにしかならない。
均質にしたければ、ブロックの書き込み回数をちゃんと記録して、分散が酷くなったら「最も書き換え頻度の低いブロックが記録しているデータ」を「最も書き換え頻度の高いブロック」に移し変える機構が必要なのです。
だから私が過去に書いたLFSではそういう機構を入れておいたんです。
# っていう話を大昔にどこかで書いたんだが、どこで書いたんだっけか…。
fjの教祖様
Re:その部分？ (スコア:3, 参考になる)
無理やりHDDに例えると、フラッシュメモリの中身は、低速で信頼性の低いHDDが無数に並んでいるようなものなので、
HDDで言うところのRAIDコントローラに相当するチップが重要です。
現状で最高速のSSDは100MB/s程度ですが、コントローラ側が速くなればまだまだ速くなります。
高速ロジックLSIの設計能力も、製造能力もあるIntelが本気で作れば、
今後急速に速度や信頼性が上がるかもしれません。
Re:その部分？ (スコア:1, すばらしい洞察)
各社がその辺りを売りにしてこないのは
・技術的に超当たり前だから（のくせにヘッポコな壊れ方をする）
・まだ売りにできないほど技術的に未熟か、実際にはまるでそんな制御していないか
なのか、ユーザーには全然区別がつかないんだよ。
Re:その部分？ (スコア:2, 参考になる)
・技術的に超当たり前だから（のくせにヘッポコな壊れ方をする）
フラッシュメモリーは wear leveling しないと使い物になりません。
「waer leveling」で検索すると、各社ともしっかりと売りにしているのがわかります。
なお、ヘッポコな壊れ方をするのは wear leveling がタコなせいではなく、
書き込み速度あげようと無理な書き込みタイミング設定しているせいです。
Re:その部分？ (スコア:1)
そんな事をしないと売り物にもならないような製品を売るとは何事だ!!
と言ってくる消費者がいるので怖くていえない、とか。
fjの教祖様
Re:その部分？ (スコア:1, 参考になる)
IO DATAのEasyDiscシリーズの上位モデル [iodata.jp]です。
「TrueFFS [windriver.com]を使っているから高信頼！」と謳っていました。
現行モデル [iodata.jp]では「SLC使ってるから高信頼！」としか書いていません。
果たして、TrueFFSではなくなったのか、他のメーカーは黙ってやって当たり前になったので売りではなくなったのか？
もしも別の優れた技術に乗り換えたりしたのであれば、明記してもおかしくありませんよね。
CFもSDもメモリスティックもxD他諸々の各種フラッシュメモリパッケージ規格だって、
「やってる」とか言われるのに確たるソースのある情報はまるで見当たりません。
どうもお詳しい様なので、何とかソースか裏づけやお墨付きの様な物はないでしょうか。
言ってることはわかりますが、理論上の話をしている様にしか見えず不安や疑念は拭えないのですよ。
Re:その部分？ (スコア:1, 興味深い)
それがないとMLCのSSDは成り立たないという感じで。
静的／動的レベルウェアリング (スコア:1, 興味深い)
データが書き込まれている部分も内部で移動して対象にする手法を静的(static)レベルウェアリングなどと
言ったりするようですね。
ざっと検索したところSSDメーカーサイトのいくつかで、静的レベルウェアリングという記述を見つけられました。
Re: (スコア:0)
そんな風になるためには*有効なファイル*が書かれているブロックと書かれていないブロックをSSDの
コントローラが区別しなければならないわけで、そのためにはコントローラがファイルシステムを
理解していなければならないと思うのだが…
でも現実のSSDは任意のファイルシステムで利用できている…
ということでウェアレベリングそんなってそんなへぼい実装にはなってないと思うよ？
# 実際どの程度賢いのかは知らないですが
Re:その部分？ (スコア:5, 参考になる)
その必要は無い。というかそんな必要があったら、「リネーミング」技術はほとんど使えないじゃないか。
話を簡単にするために、外部からは a, b, c, d の4つのブロックしか見えなくて、なおかつブロック単位でしか書き込みはしない、と仮定しよう。
内部的には 1,2,3,4,5,6の6つのブロックがある。最初は a=1, b=2, c=3, d=4 になっており、a,b,cには *有効なファイル* 情報が書き込まれているとしよう。
ファイル更新のためにファイルシステムは d を書き換えた。
(a=1, b=2, c=3, d=5) 6, 4
ファイル更新のためにファイルシステムは c を書き換えた。
(a=1, b=2, c=6, d=5) 4, 3
ファイル更新のためにファイルシステムは d を書き換えた。
(a=1, b=2, c=6, d=4) 3, 5
ファイル更新のためにファイルシステムは c を書き換えた。
(a=1, b=2, c=3, d=4) 5, 6
:
判るだろうか? 「有効なファイル」が書かれているブロックがどれなのかは判らないが、上記のように c, d を更新し続けた ssd は 3,4,5,6 のブロックを更新し続けるが、1, 2 のブロックは更新しない。
どこか適当なタイミング(私は更新頻度の差が 1k回、というのを選んだが)で、現在外部に見せているブロックを、割り当てていないものと交換する(中身はちゃんと移動してから).
:
(a=1, b=2, c=3, d=4) 5, 6
# 内部処理: 1 を 5 にコピー後、a=5にする。
(a=5, b=2, c=3, d=4) 6, 1
:
このようにすれば、更新頻度の少なかった1が次の次、あたりの書き換えで利用される。
fjの教祖様
Re: (スコア:0)
Re:その部分？ (スコア:4, 興味深い)
LFSのメタデータ管理方式と同じ要領で。
# 多分、ECCがかけてあるとは思うけどね。
つーか、その程度はもうコントローラーのマイクロコードとして入ってるって。
じゃないと、renaming 自体不可能だもの。
.
よく考えて欲しいんだが、block renaming というのは、Logical Volume Management の一種だ。LVMはなぜ可能かというと、LVM自体が「1つしかないファイル」を操作するためのファイルシステムだからだ。
block renaming のない FlashROM にLFSを実装する事は可能だ。であれば当然、LVMも実装可能で、と言う事は block renaming も実装可能だ。
.
多分こういうことを言う人は判っていないだろうと推測して、一応言っておくと、HDDも1トラックの 1/4 は「代替セクター」だ。これとは別に1トラックが丸ごと死んだ場合のための「代替トラック」も用意されている。代替セクターがある、と言う事は外に見えているセクター番号は、物理セクター番号とは全く関係ない。同一トラック内で、とはいえ入れ替わっている。
つまり、ATAのHDDも実はすでに内部で1段、仮想化されている。つまりHDDの信頼性自体、renaming によって確保されている面があり、これがないともっと圧倒的に信頼性が低くなる。
FlashROM の block renaming もそれと同じに過ぎない。
File System をデザインする際に、セクターをインターリーブにしたほうが早いとか、トラックが隣接していると早いとか…そういう技はもう殆ど役に立たないが、それはこのHDD自身が設けている仮想レイヤーの性で、物理層が全く見えなくなってしまったからだ。
と言う話を昔 Unix Magazine に書いたんだけどなぁ。
fjの教祖様
Re: (スコア:0)
> つーか、その程度はもうコントローラーのマイクロコードとして入ってるって。
> じゃないと、renaming 自体不可能だもの。
chip内のflash memoryの制御とそれらを集合させてSSDとして利用するという話は
レベルが違うんです。
HDDの場合は、あくまでリネームではなく代替セクタなのでflashのそれとは実装が
全く異なります。
# 6：一見関係ありそうで関係ない話を始める
# というやつか？
Re:その部分？ (スコア:1)
その2つは、同じモデルを異なる目的と実装方法で提供している事に過ぎない。
そしてこの場合、そもそも renaming が実装できるかどうか、だけが問題なのだ。実装方法が違っているかどうかは無意味。
関係の有無は、提供する数学モデルが一致するかどうか、で決まる。
何のために利用しているのか、ではない。
その事が判らない限り「関係の有無」を正しく判断する能力を持つ事はできんよ。
HDDと FlashROM がそれぞれ異なる目的のために利用しているのであっても、renaming のためのモデルは一緒。ACの言う「レベル」なんぞ、この場合は無意味だ。
fjの教祖様
Re: (スコア:0)
Yes
> そしてこの場合、そもそも renaming が実装できるかどうか、だけが問題なのだ。実装方法が違っているかどうかは無意味。
リネーミングの為のインターフェースを追加しなければいけません。
その追加が困難だし、容量が増加した場合にも理想的にリネーミングできるような
実装はまだ確立されているとは言えないのが状況です。
> 関係の有無は、提供する数学モデルが一致するかどうか、で決まる。
はいいですが、
> HDDと FlashROM がそれぞれ異なる目的のために利用しているのであっても、renaming のためのモデルは一緒。
HDDの書き込み回数は理論的に無限ですが、Flashは有限ですので本質的にモデルが異なります。
Re:その部分？ (スコア:1)
一緒だって。
実装のためのデバイスとその性質に拘泥すると、本質が見えなくなるぞ。
重要なのは、オブジェクトを生成・消去・検索・参照・変更できるかどうか、でしかない。その中で対象デバイスに適したやり方を選択する、というのは単なる実装論。
もちろん、だからといって、ext3 のようなファイルシステムを FlashROM 上に実装して使う愚を犯してよいわけではないが、仮にrenamingの方法が ext3 と同じ方式しかないなら、FlashROM 上に ext3 を実装すれば block renaming は可能だ。
# ただしその結果、FlashROMデバイスの寿命は縮むとは思うけどね。
この場合重要なのは
http://srad.jp/comments.pl?sid=393479&cid=1313423 [srad.jp]
という誤解を解くことにあるのであって(つまり有用なビットと無用なビットをファイルシステムレベルで識別する必要はない、ということを教えることであって)、その理解に必要なのは実装が可能だという事実だけ。実際にはどうやっているのかなどというのは、実装が可能だと理解できた後の話だ。
# もちろん、相手が AC でなければ、バックグラウンドにあわせてもう少し
# 説明をチューニングするが、ACではな。ノーヒントだから「大馬鹿」と
# 仮定するしかあるまい。
fjの教祖様
Re: (スコア:0)
>> *有効なファイル*が書かれているブロックと書かれていないブロックをSSDのコントローラが区別しなければならない
という実装例に対して、
> という誤解を解くことにある
として挙げた例がLFS、つまり他のファイルシステムを使えば問題解決するという意味の無い情報だったのですね。
俺は無駄な突っ込みをした大馬鹿だな。
Re: (スコア:0)
Re: (スコア:0)
そうやってローテーションして、どのブロックもなるべく均等に使われるようにする。
そのために必要なのは、全てのブロックの書き換え回数をカウントしておくこと。
コントローラがファイルシステムを理解する必要は全く無い。
#自明な事だと思うんだが・・・おまえら落ち着け。感情的になるなよ。
Re: (スコア:0)
コントローラーレベルで識別する必要すらない。
そもそも、なぜ必要のないファイルシステムの話を持ちだしたのか？
説明の為にファイルシステムの話を例に挙げたのかもしれないが、
だとしても、判ってる人間には判るが、判ってない人間には誤解を招く例えだ。
結果として誰にとっても役に立たないどころか害のある投稿だ。
その上うまく伝わらないからと云って相手を罵倒するのは間違っている。
子供の様に感情的になるのは慎んで欲しい。> okky
#あえてモヒカン族的に。
Re: (スコア:0)