У меня есть определенный каталог, в котором я не могу удалить файлы или каталог. Каталог находится в файловой системе ext4 с использованием RAID5 на 3 дисках на QNAP NAS.
Использование rm -f
дает мне:
rm: unable to stat `file.jpg': Input/output error
А также показывает следующее на dmesg:
EXT4-fs error (device dm-0): dx_probe:933: inode #55050534: block 3591: comm rm: Directory hole found
Поскольку "Ошибка ввода / вывода" обычно означает аппаратное обеспечение, Я провел несколько тестов, например, то, что я предполагаю, является версией QNAP fsck
, badblocks
, а также быстрые и длинные тесты SMART на отдельных дисках, плюс периодически запускается очистка рейдов в любом случае - и все вернулись и сказали, что ошибок нет.
В папке много файлов, так как это черная дыра для тысяч файлов, добавляемых ежедневно / ежечасно (невозможно посчитать их как ls | wc
, страдает от Ошибки "Ошибка ввода / вывода" и "Обнаружена дыра в каталоге") - так что на основе аналогичного сообщения о черной дыре ) Я предполагаю, что я уничтожил каталог, а не оборудование.
К сожалению, версия of find в QNAP не поддерживает аргумент -exec
, поэтому я не могу попробовать то, что было предложено в этом сообщении.
Вопросы следующие:
Выполните следующую команду внутри этого каталога. По сути, это замена -exec rm {}. Он создаст список файлов внутри каталога и построит несколько команд rm с ограничением аргументов за один запуск, установленным на 10
find ./ -type f|xargs -n 10 rm
. Выше будут удалены все файлы в этом каталоге, если это было вашим намерением. Я бы, наверное, сначала попробовал спасти файлы, скопировав их в другой каталог.
Отверстия в каталогах на самом деле являются функцией ext4 с 2013 года, но ядро Linux не было исправлено для его поддержки до конец 2019 года. Однако дыры в каталогах могут образовываться только в результате запуска fsck, поэтому это может быть косвенно вызвано ошибками данных, которые заставили вас запустить fsck.
Следующая опция fsck должна удалить все дыры в каталогах:
fsck.ext4 -Df dm-0
Обязательно запускайте на несмонтированной файловой системе (также будет работать на смонтированной файловой системе только для чтения, но есть небольшой риск того, что кто-либо читает файлы во время fsck будет получать мусор).
Имейте в виду, что это займет как минимум столько же времени, сколько и полный fsck (например, fsck.ext4 -f dm-0
), и в течение этого периода файловая система будет недоступна для использования.