抽象的な
時々、Linuxカーネルは外部USB記憶装置ドライブの書き込みキャッシュを認識しない。この場合、これらのデバイスを切り離す前にこれらのキャッシュを明示的にフラッシュする必要がありますか？
はい
WD Elements 外付けUSBハードドライブを使用していますが、次のようになりhdparm -Iます。
...
Commands/features:
Enabled Supported:
...
* Write cache
...
そしてhdparm -W：
...
write-caching = 1 (on)
一方、ドライブを接続すると、次のカーネルメッセージが表示されます。
... No Caching mode page found
... Assuming drive cache: write through
~によるとこの回答Kyle Jones の作成 これらのカーネルメッセージは、カーネルが書き込み操作がプラッタに直接移動すると仮定することを示します。
ファイルの「write_cache（RW）」セクションドキュメント/ブロック/queue-sysfs.txtカーネルが書き込みキャッシュモードを想定していることを意味するのは、Linuxカーネルのドキュメントで説明されています（ありがとう。ウェイン・コンラッド):
... "write-through", ... また、カーネルで実行されたキャッシュフラッシュを削除します。
質問
これまでのところ、Linuxシステムから外部USBストレージデバイスを取り外す標準的な方法は、マウントされているすべてのパーティションをマウント解除し、ドライブのLEDが点滅しなくなるまで待ってから、USBコネクタが消えない場合は、物理的にUSBコネクタを取り外すことでした。 USBストレージデバイス電源（一部は別々の電源があります）は明示的に電源を切るデバイスです。
このアプローチは安全ですか、または特にキャッシュがカーネルに認識されていない場合、ドライブの書き込みキャッシュからフラッシュされていないデータが失われる可能性がありますか？
後者の場合は、SCSI同期コマンドを送信してマウント解除した後、ドライブの書き込みキャッシュを明示的にフラッシュすることをお勧めします。たとえば、sg_syncsg3-utilsに付属のコマンドを使用してこれを実行できます。
sg_sync <device>
これで問題は解決しますか？または、デバイスでSCSI Stopコマンドを実行してそれを補完する必要がありますか？
後者を使用できます（再びsg3-utilsと一緒に）：
sg_start 0 -r <device>
sg_syncこの目的に適したツールですかsg_start、それとも以下の関連する方法のセクションで説明されているツールと方法のいずれかを使用するか、問題を処理するために別の手順を実行する方が良いですか？
この質問の関連性を指摘するには、次を参照してください。このコメント合格確認。
注：私は主にソフトウェアを介してハードドライブの速度を下げたり、電源を切る方法を探していません。この点で、ドライブのプラグを抜いて電源スイッチを使用することはかなり安定していることが証明されています。代わりに、ドライブにキャッシュされたデータを含む、ドライブがシャットダウンされる前に記録されたすべてのデータが不揮発性ストレージに書き込まれていることを確認する方法を探しています。
関連方法
以下では、ドライブキャッシュフラッシュまたはより一般的にリムーバブルストレージデバイスの「安全な削除」に関連して見つかった方法のいくつかの説明を提供します。 1つの側面は、既存のLinuxシステムに関連するツールの可用性です。不足しているソフトウェアを単にインストールすることは必ずしも可能ではないため、これは重要です。
デスクトップ環境：一部のデスクトップ環境では、外部USBストレージデバイスの「安全な取り外し」のためのウィジェットを提供しています。たとえば、次の質問をご覧ください。
」取り出し/安全の削除と削除著者: LGenzelis,
」Gnomeの「USBドライバの取り出し」はどのように機能しますか？「作家：k.サイボーグ。
そして関連投稿。
実装によっては、これらのウィジェットはデバイスの電源を切っているように見えますが、特にカーネルが外部ドライブキャッシュを認識しない場合、デバイスがキャッシュを早期にフラッシュするかどうかを明確にする参照が見つかりませんでした。
さらに、多くのLinuxシステム（たとえば、純粋なサーバー）にはデスクトップ環境がインストールされていません。したがって、この方法を常に使用できるわけではありません。
USBフラッシュドライブ：~によるとこの回答ジミーによって、udisksFreedesktop.orgから提供コマンドラインから外部USBストレージデバイスを安全に取り外しを使用できます。
udisks --unmount /dev/sda1
udisks --detach /dev/sda
これ良い答えTotorは、このudisks --detachコマンドが実行する操作を説明します。
- SCSI同期キャッシュコマンドの送信、
- SCSI 停止コマンドを送信します。
- USBストレージカーネルドライバのバインドを解除します。
- USBデバイスの一時停止（電源）、
- USBポートで論理的に無効/削除します。
したがって、ドライブのキャッシュを明示的に処理します。しかし、udisksこれは私が扱うべきLinuxシステムの約半分でのみ機能します。
ユディスクテル:最新バージョンのudisksは、上記のコマンドの代わりにudisksctlこのプログラムを提供します。udisksこれはもう一度根拠としたものです。ジミーの答え:
udisksctl unmount -b <partition>
udisksctl power-off -b <device>
power-off同じ答えは、コマンドの説明も引用します。udisksctl(1) のマニュアルページ:
電源を切る
ドライブを安全に取り外し、電源を切るようにしてください。オペレーティングシステム側には、ドライブを使用するプロセスがないことを確認してから、実行中のバッファとキャッシュが安定したストレージにコミットするように要求することが含まれます。
残念ながら、これは、「実行中のバッファとキャッシュ」に、カーネルが知らない外部ドライブのキャッシュが含まれるかどうかを指定しません。しかし、この点ではudisksctl前作に従う可能性が高いです。udisks
残念ながら、udisksctl既存のシステムの可用性がやや低いという点では、以前のバージョンに従います。umount
注入:~によるとマンページeject、ソフトウェア制御下でリムーバブルメディアを取り出すために使用できるコマンドラインツールです。影響を受けたパーティションは、必要に応じて早期にマウント解除されます。
このツールはリムーバブルメディアの「安全な削除」に関するいくつかの議論に登場しますが、例を参照してください。この問題寄稿者：Lgenzelisとこの問題k.Cyborgは、これに関連して削除以上の機能を実行すると提案できるものはないと述べています。
また、このツールは、デバイスよりもメディアやメディアトレイに焦点を当てているようです。これがエラーメッセージで死ぬ理由かもしれません。
eject: unable to eject
WD Elements USB ドライブに適用した場合、上記の導入例で述べました。しかし、いくつかのUSBスティックでは動作します。
それにもかかわらず、このツールはlinux-utilsの一部として可用性が高いです。
sg3-utils:これらの手順は上記で議論されsg_syncましたsg_start。
このコメントUbuntuのバグレポートによると、udiskssg3-utilsは内部でSCSI同期と停止コマンドをデバイスに送信するために使用されます。
私の考えでは、sg3-utilsはudiskよりも使いやすくなりました。しかし、これは漠然とした個人的な感想に過ぎない。
sdparm: このページ著者：Yan Liが「LinuxからUSBハードドライブを安全に取り外す」方法について説明します。これにはお勧めです。台本原則として、次のsdparmコマンドを使用してドライブのキャッシュをフラッシュし、USB HDDを停止（回転？）します。
sdparm --command=sync <device>
sdparm --command=stop <device>
これは、上記とsg_syncコマンドと同等のように見え、sg_start後者の代替として使用できます。
hdparm:ATAドライブを管理するためのツールであるhdparmUSBドライブは、ある意味ではUSBドライブへの異物です。 USBドライブは主にLinux上のSCSIデバイスと見なされるためです。 WD Elementsの例と同じ場合、SCSI-ATA変換層（SAT層）の後にATA HDDがあります。バラよりこの回答著者: Mikko Rantalainen 詳細はこちら。 SATの実装によっては、hdparmこれらのドライブは限られた機能で操作される可能性があります。
サポートされている場合は、次のコマンドを使用できます。
hdparm -F <device>
hdparm -Y <device>
ドライブのキャッシュをフラッシュしてドライブを停止します。これが不可能な場合は、次を使用することをお勧めします。
hdparm -W0 <device>
キャッシュを更新する回避策。しかし注意してください。このコマンドは、実際にドライブの書き込みキャッシュをオフにするように設計されています。したがって、単にこれまで積み重ねたキャッシュ内容を削除するのではなく、実際にリフレッシュされることを確認する必要があります。
WD Elements ドライブの場合、これらのコマンドのどれも効果がありません。代わりにbad/missing sense data。
システムファイルシステム：外部USBドライブをドライバからバインド解除したり、システムからドライブの登録を解除したり、sysfsでLinuxカーネルによって公開されたデバイス属性を操作してドライブをシャットダウンする方法がWebに散在しています。
これは例ですこの投稿Debianフォーラムのbashを介して：
echo "auto" > "/sys/bus/usb/devices/usb1/1-5/power/level"
echo "1-5:1.0" > /sys/bus/usb/devices/1-5\:1.0/driver/unbind
そして
echo "1" > "/sys/bus/usb/devices/usb1/1-5/remove"
またはこの回答著者：トニージョージ
echo 'offline' > /sys/block/sdb/device/state
echo '1' > /sys/block/sdb/device/delete
私は、これらのコードの断片を判断するためにこれらのプロパティを使用することに関して、カーネル開発者の考えの概念について十分に知りません。しかし、カーネルが知らないドライブの書き込みキャッシュをフラッシュするのに役立つかどうか疑問です。
また、これらのレシピの少なくともいくつかは古いようです。この点については「」を参照してください。システムファイルシステムルール2019年1月25日のカーネル文書から：
カーネルからエクスポートされたsysfsは、内部カーネル実装の詳細をエクスポートし、内部カーネルの構造とレイアウトに依存します。カーネル開発者は、Linuxカーネルが信頼できる内部APIを提供しないことに同意します。したがって、sysfs インターフェイスのいくつかの側面はカーネルのバージョンによって不安定になることがあります。
削除して待ちます。これは上記の質問で述べた方法です。マウントを解除した後、ドライブの書き込みアクティビティが最終的に停止するのを待つことが含まれます。次の最後のステップは、プロセス中にドライブの書き込みキャッシュをフラッシュすることです。
この質問のポイントは、これが（データへの）安全なアプローチであるかどうかを明確にすることです。
とにかく、このアプローチの最大の利点の1つは単純で、私が知っているすべてのLinuxシステムで動作し、コマンド構文がumount何十年も変更されていないことです。
追加読書
USBまたは他の外部記憶装置の「取り出し」および「安全な取り外し」の一般的な議論は、次の質問に関連して見つけることができます。
」LinuxでUSBドライブを削除する最も安全な方法Pkkm提供、
」USBドライブの取り出し/取り出しコマンド「ジョーバーは
」いつ外付けハードドライブを取り外しても安全ですか？jcoraによって書かれました。
また、ルイス・アルバラドはこの回答Ubuntuデスクトップ環境で提供されるマウント解除、取り出し、およびドライブの安全な取り外しオプション、特にドライブの安全な取り外しの違いは、単なる取り外し以上です。後者については、以下を参照してください。
多くの人は、外部ストレージデバイスがアンマウントされた場合、「安全に削除」される可能性があると主張しています。ここにいくつかの例があります。
この回答パトリックによって、
この回答depquidで、
この回答著者：イグナシオ・バスケス・エイブラムス（Ignacio Vazquez Abrams）
このコメントXhienneによって書かれました。
オフロードに加えて、いくつかの貢献は外付けHDDの回転速度を減らすことに焦点を当てています。例を見るこの問題Wincheden Springs経由。存在するこのコメント、sourcejediは、USBドライブの速度を遅くすると、機械的干渉に対する脆弱性を減らすことができると指摘しています。
他の人はUSBドライブの電源を切ることを目指しています。
次の記事では、ストレージデバイスの「安全な取り外し」に関してドライブのキャッシュを明示的に説明します。
後者は、外部ドライブの書き込みキャッシュに対するカーネルの誤った仮定によって引き起こされる可能性がある損傷を指摘する唯一の貢献です。これがまさにこの質問に関するものです。このレビューによると、単にドライブを取り外すだけでは、これらの損傷を防ぐことはできません。詳細と可能な正しいアプローチを高く評価します。
答え1
まず、これは素晴らしいとよく書かれた質問です。 OPに親指！残念ながら、ポイントが不足しているため、この質問に投票することはできません。
以下は、公式のSD規格について知っていることに基づいてmicroSDカードがどのように機能するかを簡単にまとめたものです。もちろん、これはUSBストレージデバイスでは機能しませんが、潜在的な問題について良い洞察を提供できます。
つまり、microSDカードに取り外しの準備を指示することはできますが、カードが「削除の準備」と応答した後も完全にフラッシュされない可能性がある「見えない」内部書き込みキャッシュがまだある可能性があります。注文する。 SD規格では、これらの動作をカードメーカーの裁量に任せます。したがって、通常、microSDカードは、削除される前に「見えない」書き込みキャッシュをフラッシュする不特定期間を持たなければなりません。結論は約20秒ほど待つことです。
別の例は、IntelがPCI Express拡張カードの形式の一部のエンタープライズクラスSSDについて正式に話すことです。システムの電源を入れてから約30分（正確な時間は忘れた1分）の間、システムの電源を入れないでください。以下に。 SSDは、オンボードコンデンサを電源として使用して独自の内部メンテナンスを実行できます。これは、ホストシステムの電源を入れてSSDに特定のタスクを実行するように要求しても中断できません。
これらすべてを念頭に置いて、umount(8)USBストレージデバイスを起動して使用してからしばらく待ってからUSBストレージデバイスを取り外すのが最善ですeject(1)。走るだけで十分だったが、それが私がしたことだeject(1)。特定のUSBストレージデバイスで書き込みキャッシュフラッシュ（表示または表示されていない）がどのように機能するかについての公式の低レベルの説明を見つけることができますが、他のUSBストレージデバイスは内部的に少なくともわずかに異なる方法で動作することがほぼ確実です。これらのどれも普遍的に使用することはできません。
実行して、eject -v実際に実行されている操作を確認できます。
答え2
これは実際には大きな問題であり、すでに解決策があります。これらのディスク書き込みキャッシュのために高速に実行されるデータベースは、調整されていない方法で消えると制御できません。つまり、カーネル：一般的なシステムでは、ディスク書き込みキャッシュが欠落してもデータベースはループにありません。重要なイベント。
データベースシステムは、これらのイベント（パニック、マシンチェック、BIOS例外など）の大部分が発生したときに実行されるNMIにハンドラを実装し、オープンシステムの責任と制御のギャップを解消しようとします。割り込みはマスクできません。 。 ）。 100％失敗に対処せずに、それより悪いことは絶対に完璧なものが良いものの敵になるようにしてはいけません。
このハンドラは最初にすべてのディスクキャッシュをフラッシュし、安定化時間が経過した後、ローカルマルチキャストを介してクラスタのパートナーノードに「I'm Dying」メッセージを送信し、これらのノードから数秒のタイムアウトを排除します。システムは、ノードが実際に機能しているかどうかについて再び合意に達する必要があります（暗号化は、ノードの死のニュースを絶対に信頼できるようにします）。ネットワークエラーが原因でマルチキャストメッセージがキャプチャされた場合は、まだハートビートが必要です。
その結果、クラスタ内の対応するノードの損失からの分散回復は、数ミリ秒（ほとんどの場合）内に適用でき、そのノードのディスクは損失回復の観点からほとんど何もする必要はありません。ディスクキャッシュ。
時間は重要です。
Availability = MTBF/(MTBF + MTTR)
[MTBF ==故障前の平均時間、MTTR ==修理までの平均時間。 ]
MTTR が 0 に近づくと、可用性は 1 に近づき、無数の潜在的な障害の原因がすべて排除されます。したがって、MTTRが解決すべき最初の問題です。
もちろん、データベースに優れたログリカバリ機能（無料のPostgreSQLなど）があり、バックアップに依存せず、データベースの状態と一貫して回復できない場合は、非常に低いMTTRを提供できます。失敗と超低MTTR。競合一貫性のあるデータベースの高可用性。
答え3
USB経由で接続された外付けドライブの書き込みキャッシュに関するブートエラーに対する回答をインターネットで見つけました。最初の質問に答えるには、a）はい、USBを取り外す前にバッファ/キャッシュをフラッシュすることが非常に重要です。望むかどうかにかかわらず、オペレーティングシステムがすべてがハードドライブに書き込まれることを保証するために、外部USBドライブをアンマウントする必要があることを示唆しています。 b）私が読んだすべてを読んで、すぐに私の前で答えを見つけます。 「連続書き込みを想定すると、キャッシュページコードが見つからないというエラーが発生すると思います」（journalctl -bコマンドを使用すると見つかります）は、USB経由で接続された外部ハードドライブからシステムを起動するために固有です。これは良いデザインの質問です！ USBデバイスはいつでも取り外すことができます。オペレーティングシステムの認識がない場合、または準備するのに十分な時間がないと、データが破損する可能性があります。したがって、Journalctlによって記録されたエラーはデザインの一部であるため無視されます。私にとってこれらのエラーを回避する唯一の方法は、/ etc / fstabを介してマウントせずにプラグインから自動的にマウントすることです。