Я всегда несколько параноидально относился к проверке данных, сохраненных на съемном носителе, поэтому после копирования материала на USB-накопитель или портативный жесткий диск я неизменно отключаю накопитель, перемонтирую его и сравниваю сохраненные файлы с оригиналами.
Несколько лет назад я обнаружил, что (по крайней мере, с оборудованием, которое у меня есть), я обнаружил битовые ошибки порядка 1 бит / ГБ. Каким-то образом (я забыл подробности) я обнаружил, что лекарство заключается в том, чтобы перед записью каких-либо данных сделать
echo 64 > /sys/block/sda/device/max_sectors
(при условии, что медиа отображается как sda, конечно). Пока я не забываю это делать, у меня никогда не было проблем. (Я верю по умолчанию max_sectors значение 128).
Мои вопросы:
Это только я? Я видел проблему с различными флеш-накопителями, портативными жесткими дисками, материнскими платами и ноутбуками (но никогда не проводил исчерпывающего тестирования всех комбинаций, чтобы увидеть, есть ли у меня какие-либо действительно надежные). Носители, которые использовались с окнами, и машины с двойной загрузкой окон, похоже, не имеют подобных проблем, поэтому они кажутся специфичными для Linux.
Что на самом деле вызывает проблему? Нестандартные носители, наборы микросхем, кабели?
Могу ли я что-нибудь настроить в своих системах (Debian Lenny), что автоматически установит max_sectors ? (Некоторые сценарии HAL или настройка sysctl? Более глобальный параметр / sys?). Предположительно значение по умолчанию 128 находится где-то в ядре, но кастомное ядро кажется немного радикальным.
Спасибо за любой совет
Прежде всего, когда вы получаете новое устройство, я могу порекомендовать записать на него данные, а затем проверить данные с помощью md5sum / sha1sum / ... Особенно дешевые USB-устройства имеют тенденцию выходить из строя. :( Неудивительно, что USB-ручки нормально работают на первых нескольких (сотнях) МБ, но имеют тенденцию к потере данных на последних МБ. К сожалению, многие пользователи не знают об этом и замечают проблемы слишком поздно: когда USB-ручка заполняется .
Проблема, о которой вы говорите, обычно находится на чипсете USB (хотя иногда она видна только при использовании специальных комбинаций оборудования). Если он работает с Windows, но не работает с Linux с использованием того же оборудования, это звучит так, как будто в драйвере Windows есть обходной путь, которого нет в ядре Linux (пока). И хотя Linux по умолчанию использует max_sectors = 240 (120 КБ), для Windows, по-видимому, передача 64 КБ (max_sectors = 128) http://www.linux-usb.org/FAQ.html#i5 (где также упоминаются некоторые проблемы с адаптерами производства 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/udev reload). Для тестирования вашего файла конфигурации я могу порекомендовать использовать:
# udevadm test /sys/class/block/sda/
PS: Я предпочитаю заменять оборудование, если замечаю любой проблемы, потому что обычно не стоит работать над какими-либо обходными путями (и я уверен, что вы знаете о Мерфи, который все равно поймает вас, как только вы подумаете, что у вас это работает;)).
В зависимости от количества файлов или размера файлов, я видел похожие вещи в прошлом.
Во время резервного копирования / копирования более 4 миллионов файлов .PDF мы обнаружили, что хэши MD5 для некоторых файлов НЕ совпадают!
У нас сработал rsync.
Я бы посоветовал вам попробовать выполнить rsync файлов и посмотреть, не теряете ли вы данные.
Надеюсь это поможет.
Это отлично! Я ожидаю случайного повреждения данных на всем оборудовании, но я заметил, что 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 вызывает повреждение на многих устройствах, было бы хорошо полагаться на поставщиков дистрибутивов и разработчиков ядра, чтобы они распространяли значения по умолчанию, которые фокусируются на целостности данных с общими устройствами, а не на производительности с некоторыми. Несовместимость устройств вряд ли является причиной не использовать ожидаемые настройки, когда результатом является повреждение данных.
В моей системе Ubuntu 9.04 оба /etc/udev/rules.d и /lib/udev/rules.d используются. В README рекомендует использовать /etc/udev/rules.d для локальных правил или для переопределения правил, предоставленных пакетом, которые содержатся в /lib/udev/rules.d. Также там сказано:
Демон udev наблюдает за этим каталогом с помощью inotify, чтобы изменения в этих файлах автоматически принимались, по этой причине они должны быть файлами, а не символическими ссылками на другое место, как в случае с Debian.
Я размещаю эту информацию здесь, поскольку Ubuntu основан на Debian, и эти различия могут быть важны для тех, кто может предположить, что поведение такое же.