Приветствую.
После того, как в офисе выключилось электропитание, стал проверять файловые системы. И вот для 10 файлов e2fsck выдал пресловутое сообщение.
Запуск debugfs привёл к вот таким файлам:
# debugfs -R 'ncheck -c 125090 135942 146377 149354 149355 154279 155520 178619 179280 280807' /dev/mapper/unit--725--vg--bulk-public
debugfs 1.43.4 (31-Jan-2017)
Inode Pathname
125090 /distfiles/mozilla/seamonkey/seamonkey-2.49.1/obj-x86_64-pc-linux-gnu/dist/seamonkey/libxul.so
135942 /distfiles/mozilla/seamonkey/seamonkey-2.49.2.source.tar.xz
146377 /distfiles/mozilla/seamonkey/seamonkey-2.49.1.source.tar.xz
149354 /distfiles/mozilla/seamonkey/seamonkey-x86_64-pc-linux-gnu-gtk2+alsa-2.49.2.tar.bz2
149355 /distfiles/mozilla/seamonkey/seamonkey-2.46.source.tar.xz
154279 /Java/IDEA/ideaIU-2017.2.6-no-jdk.tar.gz
155520 /Java/JBoss/6.1/jboss-as-distribution-6.1.0.Final.zip
178619 /distfiles/mozilla/seamonkey/seamonkey-2.46/obj-x86_64-pc-linux-gnu/toolkit/library/libxul.so
179280 /distfiles/mozilla/seamonkey/seamonkey-2.46/obj-x86_64-pc-linux-gnu/dist/seamonkey/libxul.so
280807 /Drivers/HP/LJM1120-Full-Solution.exe
Проверка архивов ошибок не выявила (а libxul.so — да и хрен бы с ним).
И вот тут у меня несколько вопросов.
- Файлы были записаны давно и долго не менялись, т. е. некорректная контрольная сумма с отключением питания, скорее всего, никак не связана. Раньше раздел проверки
fsckуспешно проходил. Как контрольная сумма могла «испортиться»? - Сами данные оказались корректными (благо, это архивы и можно проверить). Возможно, контрольная сумма была изначально записана неверно. Но, опять же, как?
- О каких вообще контрольных суммах идёт речь, если, насколько мне известно,
ext4(в отличие отbtrfs,zfsиhammer) использует таковые только для метаданных?
