Вопрос или проблема
Я замечаю странное явление при передаче большого количества мелких файлов (сотни тысяч фотографий, например) на внешний HDD с помощью rsync: это всегда приводит к ошибке ввода-вывода, как показано ниже (вывод команды dmesg):
[102560.315796] blk_update_request: ошибка ввода-вывода, устройство sdc, сектор 2088 операция 0x0:(ЧТЕНИЕ) флаги 0x0 физический сегмент 1 приоритет класс 0
[102560.315800] Ошибка ввода-вывода в буфере на устройстве sdc1, логический блок 5, асинхронное чтение страницы
[102560.315868] blk_update_request: ошибка ввода-вывода, устройство sdc, сектор 2184 операция 0x0:(ЧТЕНИЕ) флаги 0x0 физический сегмент 1 приоритет класс 0
[102560.315870] Ошибка ввода-вывода в буфере на устройстве sdc1, логический блок 17, асинхронное чтение страницы
[102560.315877] blk_update_request: ошибка ввода-вывода, устройство sdc, сектор 2120 операция 0x0:(ЧТЕНИЕ) флаги 0x0 физический сегмент 1 приоритет класс 0
[102560.315878] Ошибка ввода-вывода в буфере на устройстве sdc1, логический блок 9, асинхронное чтение страницы
[102560.315935] blk_update_request: ошибка ввода-вывода, устройство sdc, сектор 2088 операция 0x0:(ЧТЕНИЕ) флаги 0x0 физический сегмент 1 приоритет класс 0
[102560.315936] Ошибка ввода-вывода в буфере на устройстве sdc1, логический блок 5, асинхронное чтение страницы
[102560.315944] Ошибка ввода-вывода в буфере на устройстве sdc1, логический блок 5, асинхронное чтение страницы
[102560.315956] Ошибка ввода-вывода в буфере на устройстве sdc1, логический блок 17, асинхронное чтение страницы
[102560.315965] Ошибка ввода-вывода в буфере на устройстве sdc1, логический блок 5, асинхронное чтение страницы
[102560.315972] Ошибка ввода-вывода в буфере на устройстве sdc1, логический блок 5, асинхронное чтение страницы
[102560.315979] Ошибка ввода-вывода в буфере на устройстве sdc1, логический блок 5, асинхронное чтение страницы
После этого HDD становится не монтируемым, но каждый раз, когда это происходило, я мог исправить это с помощью ntfsfix, так что я сомневаюсь, что это проблема с оборудованием. Вывод ntfsfix приведен ниже:
Монтирование тома... $MFTMirr не соответствует $MFT (запись 0).
НЕ УДАЛОСЬ
Попытка исправить ошибки...
Обработка $MFT и $MFTMirr...
Чтение $MFT... ОК
Чтение $MFTMirr... ОК
Сравнение $MFTMirr с $MFT... НЕ УДАЛОСЬ
Исправление различий в записи $MFTMirr 0...ОК
Обработка $MFT и $MFTMirr завершена успешно.
Установка необходимых флагов на разделе... ОК
Идет очистка журнала ($LogFile)... ОК
Проверка альтернативного загрузочного сектора... ОК
Версия NTFS тома - 3.1.
NTFS раздел /dev/sdc1 был успешно обработан.
Поэтому мне действительно любопытно, что могло привести к таким частым повреждениям HDD даже для самых базовых операций ввода-вывода файлов. Повреждение HDD происходило более 20 раз за последние два дня. Это проблема системы, или rsync, или самого диска?
Еще одно странное явление: после передачи большого количества файлов, даже если ошибка ввода-вывода не возникает, размонтирование диска занимает очень много времени (~10 минут).
Я использую Ubuntu 20.04, а HDD – это Seagate SDC003 (2TB, отформатирован как NTFS).
Обновление: Вывод команды smartctl -a. Я запустил это сразу после очередной ошибки rsync.
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.15.0-69-generic] (локальная сборка)
Авторские права (C) 2002-19, Брюс Аллен, Кристиан Франке, www.smartmontools.org
=== НАЧАЛО СЕКЦИИ ИНФОРМАЦИИ ===
Семейство модели: Seagate Barracuda 2.5 5400
Модель устройства: ST2000LM015-2E8174
Серийный номер: WDZXFWCV
ID устройства LU WWN: 5 000c50 0e08ae450
Версия прошивки: 0001
Пользовательская емкость: 2,000,398,934,016 байт [2.00 TB]
Размеры секторов: 512 байт логический, 4096 байт физический
Скорость вращения: 5400 об/мин
Форм-фактор: 2.5 дюйма
Устройство: В базе данных smartctl [для получения подробной информации используйте: -P show]
Версия ATA: ACS-3 T13/2161-D ревизия 3b
Версия SATA: SATA 3.1, 6.0 Гбит/с (текущая: 6.0 Гбит/с)
Местное время: Пт Июн 16 16:28:00 2023 CST
Поддержка SMART:: Доступна - устройство имеет возможность SMART.
Поддержка SMART: Включена
=== НАЧАЛО СЕКЦИИ ЧТЕНИЯ ДАННЫХ SMART ===
Результат самодиагностики SMART: УСПЕШНО
Общие значения SMART:
Статус сбора оффлайн-данных: (0x00) Оффлайн-сбор данных никогда не начинался.
Авто сбора оффлайн-данных: Отключено.
Статус выполнения самотестирования: ( 0) Предыдущая процедура самотестирования завершилась
без ошибок или самотестирование никогда не
выполнялось.
Общее время для завершения оффлайн
сбора данных: ( 0) секунд.
Возможности оффлайн-сбора данных: (0x71) SMART выполняет оффлайн немедленно.
Нет поддержки авто оффлайн-сбора данных.
Приостановить оффлайн-сбор данных по новому
команде.
Нет поддержки оффлайн-поверхностного сканирования.
Поддержка самотестирования.
Поддержка тестирования передачи.
Поддержка выборочного самотестирования.
Возможности SMART: (0x0003) Сохраняет данные SMART перед переходом в
режим энергосбережения.
Поддерживает автоматический таймер сохранения SMART.
Возможности журнальной записи ошибок: (0x01) Поддержка журналирования ошибок.
Поддержка общего журналирования.
Рекомендуемое время опроса краткой процедуры
самотестирования: ( 1) минута.
Рекомендуемое время опроса расширенной процедуры
самотестирования: ( 326) минут.
Рекомендуемое время опроса процедуры
самотестирования передачи: ( 2) минуты.
Возможности SCT: (0x3035) Поддержка статуса SCT.
Поддержка управления функциями SCT.
Поддержка таблицы данных SCT.
Структура данных атрибутов SMART версия: 10
Специфические атрибуты SMART с порогами:
ID# НАЗВАНИЕ_АТРИБУТА ФЛАГ ЗНАЧЕНИЕ ХУДШИЙ ПОРОГ ТИП ОБНОВЛЕНО ПРИ_НЕУДАЧЕ СЫРОЕ_ЗНАЧЕНИЕ
1 Ставка_ошибок_чтения 0x000f 075 064 006 Предаварийное Всегда - 30523320
3 Время_разгона 0x0003 099 099 000 Предаварийное Всегда - 0
4 Количество_включений 0x0032 100 100 020 Старый_возраст Всегда - 449
5 Количество_перераспределенных_секторов 0x0033 100 100 036 Предаварийное Всегда - 0
7 Ставка_ошибок_поиска 0x000f 071 060 045 Предаварийное Всегда - 13036046
9 Часы_включения 0x0032 094 094 000 Старый_возраст Всегда - 6120 (197 141 0)
10 Количество_попыток_перезапуска 0x0013 100 100 097 Предаварийное Всегда - 0
12 Количество_циклов_питания 0x0032 100 100 020 Старый_возраст Всегда - 90
184 Ошибка_конц_к_концу 0x0032 100 100 099 Старый_возраст Всегда - 0
187 Неисправленный_отчет 0x0032 100 100 000 Старый_возраст Всегда - 0
188 Тайм-аут_команды 0x0032 100 100 000 Старый_возраст Всегда - 0
189 Высокие_записи 0x003a 100 100 000 Старый_возраст Всегда - 0
190 Температура_воздуха_в_Цельсия 0x0022 052 047 040 Старый_возраст Всегда - 48 (Мин/Макс 47/48)
191 Ставка_ошибок_гравитации 0x0032 100 100 000 Старый_возраст Всегда - 11
192 Количество_снижений_питания 0x0032 100 100 000 Старый_возраст Всегда - 32
193 Количество_циклов_нагрузки 0x0032 100 100 000 Старый_возраст Всегда - 1715
194 Температура_по_Цельсию 0x0022 048 053 000 Старый_возраст Всегда - 48 (0 13 0 0 0)
197 Текущий_ожидание_сектора 0x0012 100 100 000 Старый_возраст Всегда - 0
198 Оффлайн_неисправимые 0x0010 100 100 000 Старый_возраст Оффлайн - 0
199 Счетчик_ошибок_UDMA 0x003e 200 200 000 Старый_возраст Всегда - 0
240 Часы_полетов_голов 0x0000 100 253 000 Старый_возраст Оффлайн - 175 (86 165 0)
241 Всего_записанных_LBAs 0x0000 100 253 000 Старый_возраст Оффлайн - 5808417042
242 Всего_прочитанных_LBAs 0x0000 100 253 000 Старый_возраст Оффлайн - 1793836935
254 Датчик_свободного_падения 0x0032 100 100 000 Старый_возраст Всегда - 0
Версия журнала ошибок SMART: 1
Ошибок не зарегистрировано
Структура журнала самотестирования SMART версия 1
Нет зарегистрированных самотестов. [Чтобы выполнить самотесты, используйте: smartctl -t]
Структура данных выборочного самотестирования SMART версия 1
СПАН MIN_LBA MAX_LBA ТЕКУЩИЙ_СТАТУС_ТЕСТА
1 0 0 Не_тестируется
2 0 0 Не_тестируется
3 0 0 Не_тестируется
4 0 0 Не_тестируется
5 0 0 Не_тестируется
Флаги выборочного самотестирования (0x0):
После сканирования выбранных спанов, не ЧИТАТЬ остаток диска.
Если выборочное самотестирование ожидает включения питания, возобновить после 0 минут задержки.
Не совсем ответ, а скорее предположение: это может быть связано с индексаторами файлов.
Это произошло со мной с разными файловыми системами (exFAT, NTFS, ext4), разными типами внешних дисков различных брендов (WD HDD, Seagate HDD, SanDisk SSD) и операционными системами (Ubuntu, Kubuntu, MacOS). Даже если я форматирую внешний диск и начинаю заново, происходит то же самое. Однако я обнаружил, что проблема магическим образом исчезает, когда индексаторы файлов отключены. Для Kubuntu это Baloo, а для MacOS – это MDS.
Ответ или решение
Вопрос о повреждении диска при использовании rsync для передачи большого количества мелких файлов на внешние HDD, отформатированные в NTFS, является актуальным и нуждается в детальном разборе. Анализ данной ситуации требует внимания к различным аспектам — техническим, программным и системным.
1. Технические аспекты
Передача большого объема данных (в вашем случае — сотни тысяч изображений) может создавать значительную нагрузку на устройство хранения и файловую систему. NTFS, хотя и является стабильной, может страдать от ошибок, особенно если устройство перегружено. Ваши сообщения об ошибках, такие как Buffer I/O error и blk_update_request: I/O error, указывают на проблемы с доступом к определённым секторам диска.
Возможные причины:
- Ограниченные ресурсы HDD: Возможно, что ваш внешний HDD не справляется с нагрузками из-за недостаточной производительности, особенно если это диск со скоростью вращения 5400 об/мин.
- Состояние самой файловой системы: Ошибки, обнаруженные в результате анализа с помощью
ntfsfix, указывают на несоответствие между главной и резервной таблицей аляMFT, что может быть результатом некорректных операций записи в файловую систему.
2. Программные аспекты
Использование инструмента rsync без должной настройки также может привести к возникновению ошибок. При передаче большого количества мелких файлов рекомендуется учитывать параметры, которые помогут уменьшить нагрузку на хранилище.
Рекомендации:
- Используйте опцию
--bwlimitдля ограничения скорости передачи, чтобы снизить нагрузку на диск. - Попробуйте использовать параметр
--inplace, который может сократить количество операций записи. - Также вы можете использовать
--compress, чтобы уменьшить размер передаваемых файлов во время передачи.
3. Системные аспекты
Обратите внимание на параметр, связанный с индексированием файловой системы, как вы и упомянули. Системные процессы, такие как Baloo или MDS, могут оказывать влияние на доступ к диску. Если индексирование активно, это может привести к конфликтам на уровне I/O, особенно в моменты высокой нагрузки.
Решение:
- Отключите индексирование файлов во время выполнения операций
rsync.
4. Аппаратные аспекты
Вы приводите вывод команды smartctl, который показывает, что ваш диск пока что не имеет явных аппаратных ошибок. Однако стоит отметить, что всего лишь отсутствие ошибок не означает полной надежности.
Действия:
- Продолжайте мониторить другие SMART параметры, особенно
Reallocated_Sector_CtиCurrent_Pending_Sector, и если они начнут изменяться, рассмотрите возможность замены диска.
Заключение
Ваша проблема включает множество факторов, от аппаратного состояния HDD до программных взаимодействий. Проверьте состояние устройства, используемые настройки rsync и влияние индексации на процесс. Системный мониторинг и использование оптимизированных методов передачи данных помогут уменьшить вероятность повреждения диска в будущем.
Если проблемы продолжают возникать, рассмотрите возможность использования других способов обеспечения надежной передачи данных, например, архивирования и последующей передачи больших объемов данных в один файл или использование другого файлового формата, более подходящего для вашего рабочего процесса.