Ошибка EXT4-fs на loop0
Любой сценарий, в котором/(точнее, байт, а не символ, со значением 0x2f; почти все ядра Unix преднамеренно не обращают внимания на кодировку символов )находит путь в запись каталога, без ручного манипулирования необработанными блоками диска, несомненно, является ошибкой в ядре.
Такие ошибки время от времени случаются. Один случай, который я помню, читал примечания к патчу, заключается в том, что некоторые итерации эпохи 1990-х годов -… я хочу сказать Solaris, но это может быть неправильно… предлагали сервер для протокола AppleTalk Filing Protocol (AFP ), который был классическим эквивалентом NFS в MacOS. Проблема была в том, что в классической MacOS вам вполне разрешено помещать /в компонент пути; вместо этого используется разделитель каталогов :. Сервер AFP должен был выполнять моральный эквивалент tr :/ /:при сопоставлении путей, представленных клиентами, с файлами на его диске, но они пропустили пару путей кода, и поскольку сервер был реализован внутри ядра, это может фактически записать плохие записи каталога.
(См. comp.unix FAQ #2.2 , подраздел, начинающийся «Что, если в имени файла есть '/'?», для более длинной версии вышеизложенного.)
Объяснение ошибки:Эта ошибка не указывает на проблему с физическим диском; loop0— это петлевое устройство. Это блочное запоминающее устройство, которое использует файл на диске в качестве резервного хранилища. Можно сказать, диск внутри диска. Эти петлевые диски имеют свои собственные файловые системы, а иногда и собственные таблицы разделов. Таким образом, запуск fsck на физических дисках, на которых они хранятся, не будет иметь никакого эффекта
Решение
Найдите файл, поддерживающий петлевое устройство, с помощью losetup -a | grep loop0и запустите для него fsck
Решено :Я нашел виновника. Это было одно из моих изображений lxc.
Я запустил e2fsck /var/lib/vz/images/100/vm-100-disk-0.rawи теперь ошибки исчезли.