アカウント名:
パスワード:
普通、書き換え回数の平均化を行なうように分散書き込みを行なうコントローラーが入っている
そんな風になるためには*有効なファイル*が書かれているブロックと書かれていないブロックをSSDのコントローラが区別しなければならないわけで
その必要は無い。というかそんな必要があったら、「リネーミング」技術はほとんど使えないじゃないか。 話を簡単にするために、外部からは a, b, c, d の4つのブロックしか見えなくて、なおかつブロック単位でしか書き込みはしない、と仮定しよう。 内部的には 1,2,3,4,5,6の6つのブロックがある。最初は a=1, b=2, c=3, d=4 になっており、a,b,cには *有効なファイル* 情報が書き込まれているとしよう。 ファイル更新のためにファイルシステムは d を書き換えた
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: (スコア: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 を書き換えた
fjの教祖様
Re: (スコア:0)
Re: (スコア:4, 興味深い)
LFSのメタデータ管理方式と同じ要領で。
# 多分、ECCがかけてあるとは思うけどね。
つーか、その程度はもうコントローラーのマイクロコードとして入ってるって。
じゃないと、renaming 自体不可能だもの。
.
よく考えて欲しいんだが、block renaming というのは、Logical Volume Management の一種だ。LVMはなぜ可能かというと、LVM自体が「1つしかないファイル」を操作するためのファイルシステムだからだ。
block renaming のない FlashROM にLFSを実装する事は可能だ。であれば当然、LVMも実装可能で、と言う事は block renaming も実装可能だ。
.
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
#あえてモヒカン族的に。