私はしばらくLinuxを使用してきましたが、「最近の」ディストリビューション(Debian以外のすべてのディストリビューションなど)を使い始めて以来、ほとんどのUSBデバイスでI / Oの問題が発生し始めました。デフォルトでは、大量のデータを書き込もうとすると、接続が切断されるか、自動的に再開されます。システムログに次の種類のメッセージが見つかりました。
kernel: usb 1-7: reset high speed USB device using ehci_hcd and address 2
kernel: usb 2-1: device descriptor read/64, error -71
kernel: usb 2-4: new high speed USB device using ehci_hcd and address 13
これは、「ペンドライブ」とUSBで接続されたハードドライブの両方で発生します。サイズに加えて、どのデバイスが損傷したり損傷していないかを検出するのに役立つパターンが見つかりません。 1GBまたは2GBのペンドライブでこれらのメッセージが破損したことはありません(しかし、やはり人々はそうではありません)。もう販売しないでください。)
これらのエラーが発生すると、ドライブを物理的に取り外すまで、操作を実行しているすべてのプログラムと共にドライブの保留中の読み取りがロックされます。もちろん、ドライブを再接続した後、ファイルやパーティションが破損していることを発見したため、多くの作業コストが発生し、他の作業を実行するしかありませんでした。
研究を通して、私は次のことを見つけました。建築ウィキペディア またはSUSEフォーラムまたはこのコミュニティ犯人を表すのはUSBツリー属性のデフォルト値で、max_sectors
一度にUSBドライブに読み書きできるデータ量を指定します。ドライブがサポートしている以上にデバイスがリセットまたはクラッシュします。私は240
Linux()の値が間違いなくこの問題に苦しんでいない以前のカーネルやWindowsのインストール(それでも)に比べて高すぎるという言及を見つけました。128
64
私は「目が点滅する」速度(ほとんどの人がそれを願っています!)よりもデータの整合性を重視しているので、どういうわけかmax_sectors
「すべての」USBストレージデバイスの値を変更するここで「すべて」は、カスタムコマンドやルールを書く必要がないほど十分であることを意味します。残念ながら、私が試したところでは、USB自動サスペンドとは異なり、この値を変更する構成ラインまたはカーネルブートオプションが見つかりません。
私が逃したものは何ですか、次に何ができますか?私はudev
次のようにシステムを使用して次のようなものを自動的に作成できることを知っています。
SUBSYSTEMS=="usb", DRIVERS=="usb-storage", ATTRS{manufacturer}=="Some Company", ATTRS{serial}=="xxxxxxxxxx", ATTRS{max_sectors}=="240", ATTRS{max_sectors}="128"
その後、サービスを再ロードまたは再起動しましたが、見つかりませんでした。一般的なできるだけ多くのデバイスに適した十分なudev
規則です(USBプラグを介して接続されている場合)。復元またはアーカイブしたいデバイスに対してより具体的なルールを作成できることはわかっていますが、max_sectors
ここでは一種のワイルドカードにのみ興味があります。
一部のプロパティではワイルドカードを試してみましたが、ATTRS{manufacturer}=="* "
役に立ちませんでした。
udev
できるだけ多くのUSB接続デバイスを一致させるための一般的な規則は何ですか?これがソフトウェアを介してこの問題を処理する「正しい」方法ですか? (USB 2.0モジュールの削除 - 例:Ubuntuフォーラムの提案 - 少なくともFedoraがそれをカーネルに組み込んだように見えるため、オプションではないようです)。
編集する:frostschutzが提案したようにプロパティを設定するためにこれを使用しており、RUN+=
実際に動作します(を使用するのとは異なりATTR=
)。これが解決策の半分です。ほとんどすべてに一致するudevルールを作成できましたが、あまり一致しないかどうか心配です。
SUBSYSTEMS=="usb", DRIVERS=="usb-storage", \
RUN+="/bin/sh -c 'echo 64 > /sys/block/%k/device/max_sectors'"
この規則の問題は、max_sectors
64未満の値を持つデバイスを含むすべてのものに対して設定することです。私はそれをより具体的にしようとします:
SUBSYSTEMS=="usb", DRIVERS=="usb-storage", ATTRS{max_sectors}=="240", \
RUN+="/bin/sh -c 'echo 64 > /sys/block/%k/device/max_sectors'"
しかし、これはうまくいきません。私はudevルールの正しい範囲を使用していると思います(ツリーの一部を使用し、一つ父)。私は何が間違っていましたか?
編集2:以下の回答を受け入れてください。これはRUN+=
問題を解決しますが、ATTRS{…}=
何らかの理由で使用すると問題が解決しないことがわかりました。また、一般的なルールが機能しなかった理由は、udevのマンページを誤解したためです。ルールがあるはずです最大プロパティは以下で提供されます。一つ親 - これは、2つの部分を使用するには、2番目の部分が実際のデバイスでなければならないことを意味します。これら2つは基本的に完全に機能します。
SUBSYSTEM=="scsi", ATTRS{max_sectors}=="240", \
RUN+="/bin/sh -c 'echo 64 > /sys/block/%k/device/max_sectors'"
(属性の数が単数であることに注意してください。最初の属性は実際USBデバイスと2番目のデバイス一つデバイスツリーの祖先)
SUBSYSTEMS=="usb", DRIVERS=="usb-storage", ATTRS{max_sectors}=="240", \
RUN+="/bin/sh -c 'echo 64 > /sys/block/%k/device/max_sectors'"
(これは同じデバイスツリーの祖先)
次のこともできます。(確認には==、割り当てには=を使用してください):
サブシステム == "scsi", ATTRS{max_sectors} == "240", ATTRS{max_sectors} == "64"
私のシステム(Mageia 4、3.14.24コアi7)では、Kingston DT101 G2 16 GBの書き込み速度(2 MB /秒)が非常に遅く、反対の作業を実行する必要がありました。 vi /usr/lib/udev/rules.d/ 81-udisks_maxsect .rules と追加:
サブシステム == "scsi", ATTR {max_sectors} == "240", ATTR {max_sectors} = "32678"
そしてddの書き込みは3倍速かったです。 :-) mc cpはおそらく10〜20倍速かったでしょう(最初のパーティション@ 8192番目のセクタを起動し、64kソートクラスタで再フォーマットした後)。 mkfs.vfat /dev/sdh1 -n KINGSTON16G -s 128 -R 4592 そして使用 fsck.vfat -v /dev/sdh1 デフォルトのmas_sectors(240)との整列を確認すると、いくつかの安価な新しいドライブで高い書き込み増幅が発生するようです。ただし、このように高い設定を使用する場合は非常に注意する必要があります。 2048セクターでも同様の効果が得られます。
サブシステム == "scsi", ATTR{max_sectors} == "240", ATTR {max_sectors} == "2048"
既存のUSBデバイスをすべてテストしてください。それでもうまくいきます。具体的には、ルールファイルのベンダー/モデルプロパティを使用してください。
答え1
解決すべきハードウェアの問題のようです。電源USBハブ(電源関連の問題の場合)、他のUSBケーブル、前面パネルなし、他のUSBコントローラ(追加カード)、...
それでも信頼できない場合は、sync
USBメディアを使用してインストールオプションを選択できます。これによりキャッシュは発生しませんが、結果的にパフォーマンスに大きな影響を与える可能性があります。また、(フラッシュドライブの場合)追加の書き込みも可能です(たとえば、ファイルを作成してすぐに削除する場合は、非同期でファイルが最初に書き込まれませんが、同期を使用するとすべてが常にすぐに書き込まれます)。