ゼロ充填は、USBスティック/フラッシュドライブのウェアレベリングをリセットできますか？
私が理解しているように、USBスティック/フラッシュドライブのウェアレベリングは次のようになります。
- 長持ちするのに役立ちます。 （物理フラッシュセルはXX回しか書き込みできないという「摩耗」を減らします）
- 切り替える未使用のフラッシュメモリセルがある場合にのみ、実際に機能します。 （USBスティックがいっぱいになるほど、摩耗を平準化するための代替セルが少なくなります）
最悪の場合、ある時点でUSBスティックのすべてのメモリを使い果たしました。そうすれば、ある程度のウェアレベリングがまだ発生する可能性は低くなります。この状態に戻すことはできますか/（どのように）？
USBスティックに関しては何が空かという意味です
0000 0000 0000 0000（ゼロフィル）は、私にはデータと同じくらい有効であるように見えます1111 1111 1111 1111または1010 1110 0011 1111またはその他のビットパターン。
USBスティックのファームウェアは、「未使用」フラッシュセルと見なされるものを何らかの方法で認識して、ウェアレベリングに再び使用できるようにする必要があります。しかし、最終的にUSBスティック全体を一度いっぱいにした後、データが含まれていないため、ファームウェアがどのデータを「上書き」できるかを判断する方法を確認するのに問題がありますか？
だから私の質問は：ゼロ充填はUSBスティックのウェアレベリングをリセットする方法である可能性があります
おそらくこれは実装（「ファームウェア」と「メーカー」）に依存することが多いのではないかと心配していますが、「ゼロフィリング」が特定のUSBスティックをリセットできると仮定するこのアプローチにはロジックがあると思います-より良い設計-Usb-Sticks。
私が想像する論理は、ファームウェアのウェアレベリングがブロック全体（つまり、512バイトまたは2kバイト）がゼロのみに設定されることを認識するというものです。
前にブロック：1101 1011 1000 0010 ... 0001 0011
ブロック後：0000 0000 0000 0000 ... 0000 0000
このブロックから読んだとき、もちろんこの情報を受け取りたいと思います。
ブロック後：0000 0000 0000 0000 ... 0000 0000しかし、この情報は、ファームウェアでのみ使用可能な特定のフラッシュセルにそのブロックXYZ =空を保存することでオンザフライで生成できます。
この場合、情報はスティックのBLOCK XYZ =空のファームウェアメモリ部分に格納されるため、「リセット」（ゼロフィルによる）時のプールは他の目的に使用できるようになります。
そのようなファームウェアを備えているため、リセットできるUSBスティックがいくつかあるはずだと読みました。これは本当ですか？著名なメーカーの情報で裏付けられた「傾向」が質問で知りたいのですが。たぶん、この方法でリセットできるUSBスティックをリストしたリストさえ存在します。そのため、回答にはそのようなリストへのリンクを含めることができます。
また、製造された各USB-Stickによって設計された「新しいファームウェア」はなく、そのようなウェアレベリングを行う著名な（よく使用される）USBファームウェアがあると思います。したがって、そのファームウェアに関して質問に答えることができます。
せいぜい、賢い人は、このウェアレベリングが有効かどうかを（スーパーユーザーの）ユーザーが「調べる」ことができるいくつかの指示が含まれているという形式で質問に答える方法を思い付くことができます。
私の質問の背景
USBスティック/フラッシュドライブは確かに素晴らしいものです。しかし、問題は、データの保存方法が使い果たされることです。つまり、XXがデータセルに書き込んだ後です！BINGO！あなたのスティックは死んでいます！
この問題（フラッシュメモリセルへの書き込み回数は非常に少ない）を軽減する方法は、「ウェアレベリング」です。これは、可能であれば、データが常に同じフラッシュメモリセルに書き込まれるとは限らないことを気にします。
動作する方法は、データを常に同じ物理セルに書き込む代わりに、データ（変更された場合）が他の新しい物理セルに書き込まれることです。最良の場合、これはこのように続くので、これは「ストレス」を減らします。
ウェアレベリングの基本を理解しやすくするために、この概念を以下に含めました。これは、「hello」、「salut」、「hola」、「hi」の情報がという名前の論理データセルにどのように格納されるかを示しています。 ）data。これは実際には毎回異なる物理フラッシュメモリに書き込まれます（したがって、ウェアレベリングの小さな「概念」）。
状態1： [CELL1：空] [CELL2：空] [CELL3：空] =>データを書き込む "hello" 状態2： [CELL1：hello] [CELL2：empty] [CELL3：empty] data = CELL1 =>データを "salut" 状態3： [CELL1：hello] [CELL2： salut] [CELL3：empty] data = CELL2 =>データを "hola" state 4：[.____に更新します。 ] [CELL1：hello] [CELL2：salut] [CELL3：hola] data = CELL3 =>データを "hi" [.____に更新。] state5 [CELL1：hi] [CELL2：salut] [CELL3：hola] data = CELL1
4回データを書き込んだ後、各セルが平均して1.33回しか書き込まれなかったことを確認します。また、セルに「論理データ」が含まれている情報も保存および更新されることに注意してください（これには、ファームウェアがこのアカウンティングを実行する必要があります-これにも予約済みのメモリを使用します）
一部のフラッシュドライブは、書き込まれたデータがすべてゼロであるかどうかを確認し、フラッシュメモリをプログラミングする代わりにその領域のマップを解除することができます。それがどれほど一般的かはわかりませんが。
現在私はMMCコントローラー（誰が誰なのかわからない、これは秘密です:-)）で作業しており、そのファームウェアは書き込み時ではなく、後で消去とGC中にデータコンテンツをチェックします。見つかったすべてのゼロ領域のマップを解除します。
方法について
このウェアレベリングが有効かどうかを「調べて」ください。
以前に書き込まれたゼロで埋められたデータブロックとランダムで埋められたデータブロックの読み取り速度を比較してみることができます（キャッシュの使用を避けるために、書き込み後にドライブの電源を切る方が良いです）。フラッシュドライブが受信データの内容をチェックし、書き込まれた領域のマップを解除するだけの場合、コントローラーはフラッシュからの実際の読み取りをスキップできるため、この領域の読み取りははるかに高速になります（これは長い操作です）。
しかし、最終的にUSBスティック全体を一度いっぱいにした後、データが含まれていないため、ファームウェアがどのデータを「上書き」できるかを判断する方法を確認するのに問題がありますか？
TRIMは、セクターがデータを保持することを期待していないことをOSがドライブに通知できるメカニズムを提供することにより、この問題を解決することを目的としています。 TRIMはSAS/SATA仕様であり、USB仕様ではないため、残念ながら、これはUSBフラッシュドライブでは機能しません。
TRIMがないと、ドライブがデータが不要であると想定するのは安全ではありません。
ゼロ充填は、USBスティックのウェアレベリングをリセットする方法になりますか？
確かに、ファームウェアがこのように機能する場合。ファームウェアのソースコードまたは開発者向けドキュメントがなければ、確実に知る方法はありません。フラッシュチップはページとブロックで機能します。チップは一度にブロック全体（128KBなど）のみを消去できます。これは通常、USBドライブがエミュレートする従来のハードドライブセクター（512バイト）よりも大きい多くのページ（2KBなど）で構成されます。
たぶん、この方法でリセットできるUSBスティックをリストしたリストさえ存在します。そのため、回答にはそのようなリストへのリンクを含めることができます。
最近のUSBフラッシュドライブは非常に安価であるため、製造元がこの情報を提供する価値はない可能性が非常に高いです。
また、製造された各USB-Stickによって設計された「新しいファームウェア」はなく、そのようなウェアレベリングを行う著名な（よく使用される）USBファームウェアがあると思います。したがって、そのファームウェアに関して質問に答えることができます。
各USBフラッシュドライブにはマイクロコントローラー（マイクロコントローラー= CPU + ROMまたはファームウェア））があります。フラッシュドライブを開いて、チップ上の番号に基づいて検索し、タイプを見つけることができます。生産されたフラッシュドライブの総数と比較して、おそらくこれらの数は限られていますが、いくつかのコアタイプのバリエーションが非常に多いことは驚くことではありません。確かに、単一の標準ファームウェアなどはありません。そのように。
これらの一部でマイクロコントローラーを再プログラムして、特定のタイプのフラッシュドライブに仮想CD-ROMなどを作成できるチップユーティリティがあります。これは非常に文書化されていない領域であり、情報を見つけるのは困難です。運が悪かった。
しかし、問題は、データの保存方法が使い果たされることです。つまり、XXがデータセルに書き込んだ後です！BINGO！あなたのスティックは死んでいます！
いいえ、そのセルだけです。 SSD（およびSDカードとフラッシュドライブ）はオーバープロビジョニングされています。つまり、パッケージで宣伝されているよりも多くのフラッシュがあります。この余分なフラッシュは、摩耗したブロックをカバーするための「スペア」領域として使用されます。また、メーカーの欠陥もカバーしています。最初のブロックを除いて、100％保証された動作ブロックを持つフラッシュはありません。
USBストレージは、機械的（グリッド上の初期のビーズのように）でも磁気的（テープのように）でも光学的（CDのように）でもありませんが、電気的です。それぞれの場所を、時間の経過とともに（長時間）放電する小さなバッテリーセルと見なしてください。すべての書き込みは劣化を引き起こします。ゼロ充填は問題を悪化させるだけです。チップ自体には、ウェアレベリングを使用するコントローラーがあるか、使用していないかのどちらかです。ユーザーはこれを変更できません。簡単に言えば、ウェアレベリングは、USBのさまざまな部分がストレージ要件の負担のかなりの部分を占めることを保証するだけです。