USB-носитель, который можно безопасно отключить во время записи на

Question

Я сделал несколько тестов с отключением USB-носителей во время их записи. Хост-система - Linux Mint 17.1 на ноутбуке с USB 2.0. Для жестких дисков USB кажется, что после вызова 'sync' данные записываются безопасно и не будут повреждены каким-либо образом, по крайней мере, при использовании EXT4 с опцией data=journal . Это хорошо для меня, мои сценарии сначала записывают во временный каталог, затем вызывают 'sync', затем переименовывают каталог в его окончательное имя (которое должно быть атомарной операцией).

Однако мои тесты с флешкой были менее убедительными. Используя одни и те же сценарии и параметры монтирования, я постоянно сталкивался с искажениями. Более конкретно: я использую rsync с --link-dest для резервного копирования на USB-носитель. То, что я описываю как "повреждение", включает в себя файлы в резервной копии, где данные отличаются от файла в хост-системе, но время модификации - нет. Это неприятно, так как rsync будет считать эти файлы современными, если на самом деле они устарели или заполнены нулевыми байтами и т.д.

Вопрос: почему это происходит с флешками, а не с жесткими дисками? Или мне просто повезло с жесткими дисками? Есть ли смысл покупать флешку от другого производителя? Тот, который я использовал для тестирования здесь, случайно перестал работать навсегда после того, как я отключил его от сети. Так что, возможно, это был просто некачественный товар.

Answer 1

После тестирования с новой флешкой, очень похоже, что все проблемы возникли из-за поломки предыдущей флешки или низкого качества. С новой флешкой, а также с жесткими дисками я не смог повредить устройство, отключив диск во время его записи. Я даже ослабил параметры монтирования, опустив data=journal . Мои параметры монтирования теперь представлены в виде rw,noatime,errors=remount-ro и я использую EXT4.

Что касается других файловых систем, основанных на моем опыте работы с Linux Mint 17.1: XFS плохо работает при отключении в горячем режиме, часто оставляя несъемное монтирование, которое требует перезагрузки. JFS в этом отношении хороша, но удивительно медленная, почти непригодная для определенных операций. BTRFS выглядит хорошо, но Mint выпускается с устаревшей и все еще нестабильной версией, поэтому я решил не делать этого. Аналогично, NILFS2 и F2FS не очень хорошо поддерживаются в Mint в настоящее время.

Предупреждаю: хотя я не мог создать никакого повреждения при отключении в горячем режиме, пользователь по-прежнему несет ответственность за очистку буферов перед тем, как поместить файл в его окончательное местоположение. Таким образом, программа резервного копирования должна сначала скопировать во временную папку, затем вызвать sync , а затем переименовать файл или каталог в его окончательное имя (при котором в будущем ожидается полная копия).