我一直对备份到可移动介质的数据进行validation，所以在将内容复制到USB闪存驱动器或便携式硬盘后，我总是卸下驱动器，重新装入驱动器，然后使用原始文件与存储的文件进行比较。
几年前，我发现（至less在我用的设备上），我发现在1bit / GBy的数量级上有点错误。 不知何故（我忘了细节）我发现治疗是在写任何数据之前做的
echo 64 > /sys/block/sda/device/max_sectors （假设媒体当然是sda）。 只要我记得那样做，我从来没有遇到任何问题。 （我相信默认的max_sectors值是128）。
我的问题是：
这只是我吗？ 我已经看到了各种闪存驱动器，便携式硬盘驱动器，主板和笔记本电脑的问题（但从来没有做过所有组合的详尽testing，看看我是否有任何真正可靠的）。 与Windows一起使用的媒体，以及双引导窗口的机器，似乎没有类似的问题，所以它似乎是Linux特定的。
究竟是什么导致了这个问题 非标准兼容媒体，芯片组，电缆？
有什么我可以在我的系统上configuration（Debian Lenny），它会自动设置max_sectors ？ （一些HAL脚本或sysctl调整？一个更全局/ sys参数？）。 据推测，默认的128位在内核的某处，但是一个定制的内核看起来有点激烈。
感谢您的任何build议
首先当你得到一个新的设备，我可以build议写入数据，然后使用md5sum / sha1sum / …validation数据。特别便宜的USB设备往往被打破。 （USB笔在前几百MB上工作正常，但往往在最后一个MB上有数据丢失并不奇怪，可惜很多用户不知道这一点，并且注意到问题太晚了：当USB笔满了。
您所说的问题通常位于USB芯片组（尽pipe有时仅在使用硬件的特殊组合时才可见）。 如果它适用于Windows，但在使用相同硬件的Linux下失败，这听起来像是Linux内核中尚不存在的Windows驱动程序中的解决方法。 而Linux默认情况下使用的是max_sectors = 240（120kB），根据http://www.linux-usb.org/FAQ.html#i5 ，这似乎是64kB的传输（max_sectors = 128）以及由Genesys Logic制造的适配器也被提及）。
要自动设置max_sectors：使用udev执行此任务。 它允许您只为要调整的设备configurationmax_sectors。
您可以检索有关您的USB设备运行必需的信息：
# udevadm info -a -p /sys/class/block/sda/
或者更老的udev版本：
# udevinfo -a -p /sys/class/block/sda/
然后抓取你想要用于规则的属性，并创build一个像42-fix-max_sectors.rules这样的新文件，并将其放在/lib/udev/rules.d（使用最新的udev版本）或/ etc / udev /rules.d（针对较早的udev版本）。 想知道这个configuration文件是怎么样的：
SUBSYSTEM=="block", ATTRS{model}=="Voyager Mini ", RUN+="/bin/sh -c '/bin/echo 64 > /sys/block/%k/device/max_sectors'"
确保在编写规则文件（通过运行/etc/init.d/udev reload）后重新加载udev。 为了testing你的configuration文件，我可以推荐使用：
# udevadm test /sys/class/block/sda/
PS：如果我发现有任何问题，我更喜欢更换硬件，因为通常不值得花费任何解决方法（我确信你知道墨菲如果你认为自己能够抓住你，它工作;））。
根据文件的数量或者文件的大小，过去我也看过类似的东西。
在备份/拷贝超过4百万个.PDF文件的过程中，我们发现某些文件上的MD5哈希值是不一样的！
我们的工作是rsync。
我build议你尝试的一件事是rsync的文件，看看你是否仍然遇到数据丢失。
希望这可以帮助。
在我的Ubuntu 9.04系统上，使用/etc/udev/rules.d和/lib/udev/rules.d 。 READMEbuild议对本地规则使用/etc/udev/rules.d ，或者覆盖/lib/udev/rules.d中包含的软件包提供的规则。 另外，它说：
udev守护进程使用inotify函数监视这个目录，这样对这些文件的修改就会被自动拾取，因为这个原因，它们必须是文件而不是象Debian那样的符号链接到另一个位置。
我在这里发布这个信息，因为Ubuntu是基于Debian的，这些差异对于那些可能认为行为是相同的人来说可能是重要的。
这很好！ 我期望在所有硬件上随机数据损坏，但我注意到USB设备非常差，这是一个持续的噩梦。 很显然，根本原因是蹩脚的USB芯片组与协议和文件系统开发人员，不关心数据完整性，但一个解决scheme，使USB设备可用非常赞赏。
你仍然应该总是期望数据损坏，因为你不知道你会遇到什么样的新问题。 在复制大型数据集之前，请保留所有文件的散列，然后再进行validation。
cd /oldfs find . -type f -exec md5sum {} \; >& /oldfs.md5 rsync -a . /newfs/ cd /newfs md5sum -c /oldfs.md5 | grep -v OK$
现在已经发现max_sectors的默认设置在很多设备上都会导致损坏，所以依靠发行版供应商和内核开发者来分发关注数据完整性和普通设备的默认设置是非常好的，而不是仅仅依靠一些设备来提高性能。 不符合要求的设备几乎不是使用他们期望的设置的原因，当数据损坏的结果。