Носитель USB - проблемы целостности данных в Linux
Я всегда был несколько параноидален в отношении проверки данных, зарезервированных на съемный носитель, поэтому после копирования содержимого на USB-накопитель или переносной жесткий диск я неизменно отключаю диск, перемонтирую его и разлагаю сохраненные файлы с оригиналами.
Несколько лет назад я обнаружил, что (по крайней мере, с оборудованием, которое у меня есть), я видел битовые ошибки на уровне порядка 1 бит / Гбайт. Каким-то образом (я забыл детали) я обнаружил, что лечение, прежде чем писать какие-либо данные,
echo 64 > /sys/block/sda/device/max_sectors
(при условии, что СМИ появляются как sda, конечно). Пока я помню, что у меня никогда не было проблем.
(Я верю дефолту max_sectors значение 128).
Мои вопросы:
Это только у меня так? Я видел проблему с различными флэш-накопителями, портативными жесткими дисками, материнскими платами и ноутбуками (но никогда не проводил исчерпывающего тестирования всех комбинаций, чтобы выяснить, есть ли у меня какие-либо, которые действительно надежны). Носители, которые использовались с Windows, и машины, на которых установлены окна с двойной загрузкой, похоже, не имеют подобных проблем, поэтому, похоже, они специфичны для Linux.
Что на самом деле вызывает проблему? Являются ли нестандартные носители, чипсеты, кабели?
Есть ли что-нибудь, что я могу настроить в своих системах (Debian Lenny), которое автоматически установит
max_sectors? (Некоторые скрипты HAL или твик sysctl? Более глобальный параметр /sys?). Предположительно, по умолчанию 128 находится где-то в ядре, но собственное ядро кажется немного радикальным.
Спасибо за любой совет
4 ответа
Прежде всего, когда вы получаете новое устройство, я могу порекомендовать записать на него данные и впоследствии проверить их, используя 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 (где возникают проблемы). также упоминаются адаптеры 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.
Одна вещь, которую я бы посоветовал вам попробовать - это повторно выполнить синхронизацию файлов и проверить, не потеряны ли все еще данные.
Надеюсь это поможет.
В моей системе 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, и эти различия могут быть важны для тех, кто может предположить, что поведение такое же.
Это отлично! Я ожидаю случайного повреждения данных на всех аппаратных средствах, но я заметил, что 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 вызывает повреждение на многих устройствах, было бы хорошо полагаться на поставщиков дистрибутивов и разработчиков ядра, чтобы распространять значения по умолчанию, ориентированные на целостность данных с обычными устройствами, а не на производительность с несколькими. Несоответствие устройств едва ли является причиной того, что они не используют ожидаемые настройки, когда в результате происходит повреждение данных.