アカウント名:
パスワード:
・正しいSSDの使い方結局デフラグをした方がいいのかどうかがわからない「まんべんなく領域全体を使うために、断片化したような状態で使うほうがいい」「空き領域のゼロクリアはした方が良い」「FATでフォーマットしろ(いやです)」「むしろ何もしない方がいい」「SSDを使うな」今そこにあるプチフリを何とかしたいんだけど。
まず、SSDは外部に見せているアドレスと、内部で管理しているアドレスが全くリンクしていません。HDDでも bad sector になると代替セクターに移動しますが、そうなるまでは外部に見せているアドレスの連続性と、内部での連続性は一応保たれています(track 単位で、ですが)。しかし、SSDはblock単位でてんでバラバラ。blockとして連続していても、内部的には全然離れた block にアサインされている事が多い。
なので、外部から「デフラグ」をしかけても、それは単に外部から見て連続しているだけで、内部的には不連続。というか不連続さがひどくなって終わる可能性の方が高い。
なので デフラグはするな。 これが基本。
.
次に空き領域のゼロクリア。HDDエミュレーションモードで使っているときに、古いファイルのゴミイメージが残っていると、同じ block 上の別セクタ…つまり同じblockを共有している、別の小さな部分…を上書きする際に、全 block を一旦消してからゴミイメージを書き込む。なのでこれは無駄…と言うのは判る。問題は「0x00 fill」なのか「0xff fill」なのか、というポイント。FlashROM は構造上、一旦全ビットを 1 にして、必要に応じて0の部分を作っていく、という書き方をします。そう考えると、これは「0xff fill」じゃないのか??? とか、いや、内部回路がゼロクリアを考慮に入れて、読み出したビットパターンを全部1/0逆転させたらゼロクリアでいいじゃん…とか難しいことになる。
なので、これはそもそも「クリアするパターン」をしらない限り解けない問題なので、解かない方法を考えるべき。
FATでフォーマット…これはやめておけ。単純にやめておけ。
FATは FAT table 上にもディレクトリテーブル上にも、512byte 単位よりも小さな単位で更新するものが大量に存在し、なおかつ read cache はほとんど存在しない実装が多い。MS-DOS とか Win95 なんか典型的にそうで、128byte 単位の書き込みとかがHDDに送り付けられたりする。HDDには1セクタの一部分だけを modify する機能が要求されているので、一応これはできるし、SSDもできるけれど、そんな小さな単位でIOされてもSSDの block 更新頻度が跳ね上がるだけでちっとも嬉しくない。
だからやめておけ。
じゃぁ、どうするべきかというと、SSDを「一人Raid5」だと思え が正解。それも、チェックサム用のセクターを持たない Raid5。blockが…例えば 128kbyte/block の SSD なら、ファイルシステムを作るときに
「これは Raid5 だから。1ブロックは 128kbyte だから。それ以下の単位でIOするの禁止っ!!!」
と宣言してあげる(ただし、NTFSでどうやるのかは判らない。もしかすると Vista 以降でないとできないとか、Windows Server でないとできないとか、そういう制約はあるかもしれない)。
すると、block 単位のIOしかできなくなるし、ファイルシステムも更新をそのような単位で行うようになる。解決策は以上。
これで、ゼロクリア問題は解決する。「使っていないセクターと使っているセクターが入り交じった block」はもう発生しない。ファイルを消してブロックを使わなくなったら、そのブロックは更新されなくなる。故に SSD 上の block も更新されなくなる。
注意点として、「パーティションを切ってはいけない」と言うのがある。全ディスクを、パーティションを切らずに、1つのファイルシステムでつかう。あるいは、パーティションを切る場合は、パーティションの開始が block の alignment と一致するように、注意深く設定すること。でないと、128kbyte 単位の block で、IOも128kbyte単位なのに、実体は常に「あるブロックの後半64kbyte と次のブロックの前半 64kbyte を更新している」などというできの悪い、IO時間が2倍かかる結果に終わる。
次の注意点は、block size がいくつなのか注意深く調べろ、というもの。上記の例では 1block 128kbyte としたが、こんなに「小さい」のはまれだ。256kbyte とか 512kbyte とかの製品が当たり前のように存在する。自分が使っているSSDのスペックは本当はいくつなのか、外に見せているインターフェースじゃなくって内部の実装がどうなっているのか、を調べて調べて調べまくれ。
以上のことを守れば、「内部で仮想的なセクター番号を物理的な block 番号とオフセットに置き換える作業が忙しすぎて、外部にIOが返せなくなる」プチフリ現象は圧倒的に削減出来る。
まぁ、最大の問題点は、必要な情報を得るために実験を繰り返すとなるとそれ自体がSSDに取って負担となることで…
詳細な解説をありがとうございます。これほど疑問点に対する回答を、まとまった形で一ページにしている方を見たことはないので、とても勉強になりました。
「IOの回数をとにかく減らす」が肝要ということなのですね。SSDの正答は「RAIDを組んで、チャンクをSSDのブロックサイズと合わせる」ということですか。しかし、例えばノートPCのような標準で、多くの機種で現実的ではないような気がします。
Vista以降でというお話ですので「64kb以上のクラスタサイズでフォーマットできるようになった」ということに関連しているのならば、例えば「ブロック単位が512kbのSSDを、アロケーションユニットサイズを512kbでフォーマット」することで同様の効果が得られるという理解で良いのでしょうか。(SSDでクラスタサイズを大きくとるというのは、聞いたことがあるのですが)
「(最初の設定をきちんとしたら)何もしない(できることがない)」ということだと、ええいもう後はチップコントローラにおまかせだーい。と言うしかないような…
SSDの正答は「RAIDを組んで、チャンクをSSDのブロックサイズと合わせる」ということですか。
そうじゃありません。RAIDを組む必要はない。1台のSSDでもRAIDとみなすって事です。普通はHDD1台をRAIDと考える、なんてことはしませんが、RAIDと考えろ、と。ただし、次の問題が出ちゃいます。
ノートPCのような標準で、多くの機種で現実的ではないような気がします。
これは、まぁ、ね。しょうがない。特にCドライブとか、Linux の大抵の distribution だと /boot とか、小さいIO単位で記録しておかないと容量的にすぐパンクするような世界では…512Gbyteぐらいの容量を待つ必要があるのかも。
USBメモリ bootable にしておいて、boot image と /tmp を USBメモリ上に作成、どんどんボロくなっていくUSBメモリ自体はどんどん捨てていく…という発想もありかもしれない、とは思っているのですが、この辺りは私も良い答は見つけられていません。
私の場合、LinuxマシンがSSDなんですが、128Gbyte SSD を /boot と / で作っておいて、/bootのサイズを使って、/ のスタートアドレス・アライメントを合わせつつ、/boot はちんまいIOでも諦める。/ はデカイchunksize にする、という作り方をしています。とりあえず、プチフリの類は経験していませんが…SSDに対する負担がでかいかもしれないな、とは思っています。
例えば「ブロック単位が512kbのSSDを、アロケーションユニットサイズを512kbでフォーマット」することで同様の効果が得られるという理解で良いのでしょうか。
多分、それで同じ効果が得られるはずです。
「(最初の設定をきちんとしたら)何もしない(できることがない)」ということだと、
そこがフォーマットと言われる代物の怖いところですね。
はじめに。すみません、脱文がありました。訂正する必要も無いようなので、自戒をかねて、そのままにしておきます。
私の環境がネットブックに標準搭載の8GBです。当初の導入理由がパフォーマンスの向上ではなく「電力消費の軽減・静音化」でした。運用の仕方も「容量の節約・寿命をのばす」ことに重点を置いていたので、それにそぐわない方法には無関心だったようです。
次回のリカバリ時に、フォーマットの設定を確認することにします。フォーマット作業は細かく設定できるLinuxのfdiskから行った方が良さそうですね。あまりクラスタサイズに留意することはなかったのですが、大容量のSDカードなどNANDフラッシュ全般に応用が効きそうです。とても参考になりました。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
いや、これは簡単だろう (スコア:3, 参考になる)
まず、SSDは外部に見せているアドレスと、内部で管理しているアドレスが全くリンクしていません。HDDでも bad sector になると代替セクターに移動しますが、そうなるまでは外部に見せているアドレスの連続性と、内部での連続性は一応保たれています(track 単位で、ですが)。
しかし、SSDはblock単位でてんでバラバラ。blockとして連続していても、内部的には全然離れた block にアサインされている事が多い。
なので、外部から「デフラグ」をしかけても、それは単に外部から見て連続しているだけで、内部的には不連続。というか不連続さがひどくなって終わる可能性の方が高い。
なので デフラグはするな。 これが基本。
.
次に空き領域のゼロクリア。HDDエミュレーションモードで使っているときに、古いファイルのゴミイメージが残っていると、同じ block 上の別セクタ…つまり同じblockを共有している、別の小さな部分…を上書きする際に、全 block を一旦消してからゴミイメージを書き込む。なのでこれは無駄…と言うのは判る。問題は「0x00 fill」なのか「0xff fill」なのか、というポイント。FlashROM は構造上、一旦全ビットを 1 にして、必要に応じて0の部分を作っていく、という書き方をします。そう考えると、これは「0xff fill」じゃないのか??? とか、いや、内部回路がゼロクリアを考慮に入れて、読み出したビットパターンを全部1/0逆転させたらゼロクリアでいいじゃん…とか難しいことになる。
なので、これはそもそも「クリアするパターン」をしらない限り解けない問題なので、解かない方法を考えるべき。
.
FATでフォーマット…これはやめておけ。単純にやめておけ。
FATは FAT table 上にもディレクトリテーブル上にも、512byte 単位よりも小さな単位で更新するものが大量に存在し、なおかつ read cache はほとんど存在しない実装が多い。MS-DOS とか Win95 なんか典型的にそうで、128byte 単位の書き込みとかがHDDに送り付けられたりする。HDDには1セクタの一部分だけを modify する機能が要求されているので、一応これはできるし、SSDもできるけれど、そんな小さな単位でIOされてもSSDの block 更新頻度が跳ね上がるだけでちっとも嬉しくない。
だからやめておけ。
.
じゃぁ、どうするべきかというと、SSDを「一人Raid5」だと思え が正解。それも、チェックサム用のセクターを持たない Raid5。blockが…例えば 128kbyte/block の SSD なら、ファイルシステムを作るときに
「これは Raid5 だから。1ブロックは 128kbyte だから。それ以下の単位でIOするの禁止っ!!!」
と宣言してあげる(ただし、NTFSでどうやるのかは判らない。もしかすると Vista 以降でないとできないとか、Windows Server でないとできないとか、そういう制約はあるかもしれない)。
すると、block 単位のIOしかできなくなるし、ファイルシステムも更新をそのような単位で行うようになる。
解決策は以上。
これで、ゼロクリア問題は解決する。「使っていないセクターと使っているセクターが入り交じった block」はもう発生しない。ファイルを消してブロックを使わなくなったら、そのブロックは更新されなくなる。故に SSD 上の block も更新されなくなる。
.
注意点として、「パーティションを切ってはいけない」と言うのがある。全ディスクを、パーティションを切らずに、1つのファイルシステムでつかう。あるいは、パーティションを切る場合は、パーティションの開始が block の alignment と一致するように、注意深く設定すること。
でないと、128kbyte 単位の block で、IOも128kbyte単位なのに、実体は常に
「あるブロックの後半64kbyte と次のブロックの前半 64kbyte を更新している」
などというできの悪い、IO時間が2倍かかる結果に終わる。
次の注意点は、block size がいくつなのか注意深く調べろ、というもの。上記の例では 1block 128kbyte としたが、こんなに「小さい」のはまれだ。256kbyte とか 512kbyte とかの製品が当たり前のように存在する。自分が使っているSSDのスペックは本当はいくつなのか、外に見せているインターフェースじゃなくって内部の実装がどうなっているのか、を調べて調べて調べまくれ。
.
以上のことを守れば、「内部で仮想的なセクター番号を物理的な block 番号とオフセットに置き換える作業が忙しすぎて、外部にIOが返せなくなる」プチフリ現象は圧倒的に削減出来る。
まぁ、最大の問題点は、必要な情報を得るために実験を繰り返すとなるとそれ自体がSSDに取って負担となることで…
fjの教祖様
Re:いや、これは簡単だろう (スコア:1)
詳細な解説をありがとうございます。
これほど疑問点に対する回答を、まとまった形で一ページにしている方を見たことはないので、とても勉強になりました。
「IOの回数をとにかく減らす」が肝要ということなのですね。
SSDの正答は「RAIDを組んで、チャンクをSSDのブロックサイズと合わせる」ということですか。
しかし、例えばノートPCのような標準で、多くの機種で現実的ではないような気がします。
Vista以降でというお話ですので「64kb以上のクラスタサイズでフォーマットできるようになった」ということに関連しているのならば、
例えば「ブロック単位が512kbのSSDを、アロケーションユニットサイズを512kbでフォーマット」することで同様の効果が得られるという理解で良いのでしょうか。
(SSDでクラスタサイズを大きくとるというのは、聞いたことがあるのですが)
「(最初の設定をきちんとしたら)何もしない(できることがない)」ということだと、
ええいもう後はチップコントローラにおまかせだーい。と言うしかないような…
光の速さで歩けは無茶だ!せめて走らせろ!
Re:いや、これは簡単だろう (スコア:1)
そうじゃありません。RAIDを組む必要はない。1台のSSDでもRAIDとみなすって事です。普通はHDD1台をRAIDと考える、なんてことはしませんが、RAIDと考えろ、と。ただし、次の問題が出ちゃいます。
これは、まぁ、ね。しょうがない。特にCドライブとか、Linux の大抵の distribution だと /boot とか、小さいIO単位で記録しておかないと容量的にすぐパンクするような世界では…512Gbyteぐらいの容量を待つ必要があるのかも。
USBメモリ bootable にしておいて、boot image と /tmp を USBメモリ上に作成、どんどんボロくなっていくUSBメモリ自体はどんどん捨てていく…という発想もありかもしれない、とは思っているのですが、この辺りは私も良い答は見つけられていません。
私の場合、LinuxマシンがSSDなんですが、128Gbyte SSD を /boot と / で作っておいて、/bootのサイズを使って、/ のスタートアドレス・アライメントを合わせつつ、/boot はちんまいIOでも諦める。/ はデカイchunksize にする、という作り方をしています。とりあえず、プチフリの類は経験していませんが…SSDに対する負担がでかいかもしれないな、とは思っています。
.
多分、それで同じ効果が得られるはずです。
そこがフォーマットと言われる代物の怖いところですね。
fjの教祖様
Re:いや、これは簡単だろう (スコア:1)
はじめに。
すみません、脱文がありました。
訂正する必要も無いようなので、自戒をかねて、そのままにしておきます。
私の環境がネットブックに標準搭載の8GBです。
当初の導入理由がパフォーマンスの向上ではなく「電力消費の軽減・静音化」でした。
運用の仕方も「容量の節約・寿命をのばす」ことに重点を置いていたので、それにそぐわない方法には無関心だったようです。
次回のリカバリ時に、フォーマットの設定を確認することにします。
フォーマット作業は細かく設定できるLinuxのfdiskから行った方が良さそうですね。
あまりクラスタサイズに留意することはなかったのですが、大容量のSDカードなどNANDフラッシュ全般に応用が効きそうです。
とても参考になりました。
光の速さで歩けは無茶だ!せめて走らせろ!