web-dev-qa-db-ja.com

USBストレージメディア-Linuxでのデータ整合性の問題

私はリムーバブルメディアにバックアップされたデータの検証について常にやや偏見を持っていたので、USBフラッシュドライブまたはポータブルHDDにデータをコピーした後、常にドライブをアンマウントして再マウントし、保存されているファイルを元のファイルとdiff-qします。

数年前、私は（少なくとも私が持っている機器では）1ビット/ギガバイトのオーダーのビットエラーが発生していることを発見しました。どういうわけか（詳細を忘れてしまいました）データを書き込む前に、治療法は次のことであることがわかりました

echo 64 > /sys/block/sda/device/max_sectors

（もちろん、メディアがsdaとして表示されると仮定します）。それを覚えている限り、問題はありませんでした。 （私はデフォルトのmax_sectors値が128であると信じています）。

私の質問は次のとおりです。

  • これは私だけですか？さまざまなフラッシュドライブ、ポータブルHDD、マザーボード、ラップトップで問題が発生しました（ただし、実際に信頼できるものがあるかどうかを確認するために、すべての組み合わせを徹底的にテストしたことはありません）。 Windowsで使用されているメディア、およびWindowsをデュアルブートするマシンでは、同様の問題は発生していないようであるため、Linux固有のようです。

  • 実際に問題を引き起こす原因は何ですか？非規格に準拠したメディア、チップセット、ケーブルはありますか？

  • max_sectorsを自動的に設定するシステム（Debian Lenny）で構成できるものはありますか？ （いくつかのHALスクリプトまたはsysctl Tweak？よりグローバルな/ sysパラメーター？）。おそらくデフォルトの128はカーネルのどこかにありますが、カスタムカーネルは少し抜本的です。

アドバイスをありがとう

linuxdebianusbusb-flash-drivedata-integrity
6
timday

まず、新しいデバイスを入手したら、それにデータを書き込んでから、md5sum/sha1sum/...を使用してデータを確認することをお勧めします。特に安価なUSBデバイスは壊れがちです。 :( USBペンが最初の数（100）MBで正常に動作するのは珍しいことではありませんが、最後のMBでデータが失われる傾向があります。悲しいことに、多くのユーザーはそのことに気づかず、問題に気付くのが遅すぎます。USBペンがいっぱいになると。

あなたが話している問題は通常、USBチップセットにあります（ハードウェアの特別な組み合わせを使用している場合にのみ表示される場合もあります）。 Windowsで動作するが、同じハードウェアを使用するLinuxで失敗する場合、これはLinuxカーネルに（まだ）存在しないWindowsドライバーに回避策があるように思われます。また、Linuxはデフォルトでmax_sectors = 240（120kB）を使用しますが、 http://www.linux-usb.org/FAQ.html#i5）によると、Windowsでは64kB転送（max_sectors = 128）のようです。 （Genesys Logicによって作成されたアダプターに関するいくつかの問題も言及されています）。

Max_sectorsを自動的に設定するには：このタスクにはudevを使用します。調整したいデバイスだけにmax_sectorsを設定できます。

実行中のUSBデバイスに関する必要な情報を取得できます。

# udevadm info -a -p /sys/class/block/sda/

または古いudevバージョンの場合：

# udevinfo -a -p /sys/class/block/sda/

次に、ルールに使用する属性を取得し、42-fix-max_sectors.rulesのような新しいファイルを作成して、/ lib/udev/rules.d（最近のudevバージョンを使用する場合）または/ etc/udevの下に配置します。 /rules.d（古いudevバージョンの場合）。この構成ファイルがどのように見えるかを理解するには、次のようにします。

SUBSYSTEM=="block", ATTRS{model}=="Voyager Mini    ", RUN+="/bin/sh -c '/bin/echo 64 > /sys/block/%k/device/max_sectors'"

ルールファイルを書き込んだ後、必ずudevをリロードしてください（/etc/init.d/udevreloadを実行して）。構成ファイルをテストするには、次の使用をお勧めします。

# udevadm test /sys/class/block/sda/

PS：anyの問題に気付いた場合は、ハードウェアを交換することを好みます。通常、回避策に取り組む価値はないからです（そして、きっとあなたはあなたがそれが機能していると思うとすぐにとにかくあなたを捕まえるであろうマーフィーに気づいてください;））。

4
Michael Prokop

ファイルの数やサイズにもよりますが、私は過去に同様のことを見てきました。

400万を超える.PDFファイルのバックアップ/コピー中に、一部のファイルのMD5ハッシュが同じではないことがわかりました。

私たちのために働いたのはrsyncでした。

ファイルをrsyncして、データが失われるかどうかを確認することをお勧めします。

お役に立てれば。

2
KPWINC

私のUbuntu9.04システムでは、/etc/udev/rules.dと/lib/udev/rules.dの両方が使用されています。 READMEは、ローカルルールに/etc/udev/rules.dを使用するか、/lib/udev/rules.dに含まれるパッケージ提供のルールをオーバーライドすることをお勧めします。また、それは言う：

Udevデーモンはinotifyでこのディレクトリを監視し、これらのファイルへの変更が自動的に取得されるようにします。このため、これらのファイルはファイルである必要があり、Debianの場合のように別の場所へのシンボリックリンクではありません。

UbuntuはDebianベースであるため、この情報をここに投稿します。これらの違いは、動作が同じであると考える人にとって重要な場合があります。

1
Paused until further notice.

これは素晴らしいです！すべてのハードウェアでランダムなデータ破損が予想されますが、USBデバイスが非常に貧弱であるため、悪夢が続いていることに気づきました。明らかに根本的な原因は、データの整合性を気にしないプロトコルおよびファイルシステムの開発者と組み合わされた安っぽいUSBチップセットでしたが、USBデバイスを使用可能にする回避策は非常に高く評価されています。

データの破損は、それを引き起こす可能性のある新しい問題がわからないため、常に予想する必要があります。大きなデータセットをコピーする前にすべてのファイルのハッシュを保持し、後でそれらを確認します。

cd /oldfs
find . -type f -exec md5sum {} \; >& /oldfs.md5
rsync -a . /newfs/
cd /newfs
md5sum -c /oldfs.md5 | grep -v OK$

Max_sectorsのデフォルト設定は多くのデバイスで破損を引き起こすことがわかったので、少数のパフォーマンスではなく、一般的なデバイスとのデータ整合性に焦点を当てたデフォルトを配布するために、配布ベンダーとカーネル開発者に頼るのがよいでしょう。データの破損が発生した場合、デバイスが非準拠であることは、期待する設定を使用しない理由にはなりません。

1
carlito