В роли шляпы тут подсуетился сервер под управлением Мандривы 2008.1.
Упал и все тут. Видно, компании Intel не нравились решения на платформе VIA, и она вошла в альянс с Торвальдсом, который заложил в VIA-дрова такие бэк-мины, которые обрушивают сервера на VIA хоть и не часто, но зато в самое неподходящее время (часть из этого утверждения — шутка )
После поднятия сервера и прогона FSCK встал неувядающий вопрос — что с этим мусором делать?
-
# fsck -v -n /dev/sda3
-
fsck 1.40.8 (13-Mar-2008)
-
e2fsck 1.40.8 (13-Mar-2008)
-
Warning! /dev/sda3 is mounted.
-
Warning: skipping journal recovery because doing a read-only filesystem check.
-
/dev/sda3 contains a file system with errors, check forced.
-
Pass 1: Checking inodes, blocks, and sizes
-
Inodes that were part of a corrupted orphan linked list found. Fix? no
-
-
Inode 229827 was part of the orphaned inode list. IGNORED.
-
Inode 229828 was part of the orphaned inode list. IGNORED.
-
Deleted inode 229829 has zero dtime. Fix? no
-
-
Inode 229830 was part of the orphaned inode list. IGNORED.
-
Inode 229831 was part of the orphaned inode list. IGNORED.
-
Inode 229832 was part of the orphaned inode list. IGNORED.
-
Inode 229833 was part of the orphaned inode list. IGNORED.
-
Inode 229834 was part of the orphaned inode list. IGNORED.
-
Inode 229840 was part of the orphaned inode list. IGNORED.
-
Inode 229842 was part of the orphaned inode list. IGNORED.
-
Inode 229847 was part of the orphaned inode list. IGNORED.
-
Inode 229860 was part of the orphaned inode list. IGNORED.
-
Pass 2: Checking directory structure
-
Pass 3: Checking directory connectivity
-
Pass 4: Checking reference counts
-
Pass 5: Checking group summary information
-
Block bitmap differences: -918019 -923649 —(927744—927745) -929792 -931843 -937985 -937987 -940033 -944128
-
Fix? no
-
-
Free blocks count wrong (4778377, counted=4778374).
-
Fix? no
-
-
Inode bitmap differences: —(229827—229834) -229840 -229842 -229847 -229860
-
Fix? no
-
-
/dev/sda3: ********** WARNING: Filesystem still has errors **********
-
-
85838 inodes used (6.54%)
-
658 non-contiguous inodes (0.8%)
-
# of inodes with ind/dind/tind blocks: 2734/26/0
-
464503 blocks used (8.86%)
-
0 bad blocks
-
1 large file
-
-
55030 regular files
-
5334 directories
-
3393 character device files
-
13603 block device files
-
1 fifo
-
817 links
-
8452 symbolic links (8449 fast symbolic links)
-
4 sockets
-
———
-
86634 files
-
#
1. Понятное, что самое простое — вместо «N» ответить «Y», и тогда все будет исправлено и почикано в лучшем виде.
Якобы. Поэтому все-таки прежде чем чикать, хотелось бы прежде узнать — какие файлы реально пострадали? Чтобы их лучше сразу выбросить, чем хранить и потом иметь проблемы с их использованием.
2. Если кто-то помнит, в винде когда-то была такая утилита от лаборатории «Диалог-Наука» — Adinf32, которая по запросу или шедулеру проверяла контрольные суммы файлов на жестком диске. Т.е. проверяла их целостность и сохранность — очень важное свойство архивов.
У Касперского, кажется, тоже был подобный проект, Inspector, или как-то иначе.
Что из аналогов есть в нашем любимом линуксе?
PS. Написать скрипт, который только проверяет контрольные суммы файлов, не составляет труда, но по сравнению с расширенными возможностями указанных утилит это очень мало.
Самый безопасный и простой рецепт, которым можно проверить дисковые разделы, в том числе и системный рутовский, и исправить найденные в файловой системе ошибки, обнаружился в команде shutdown:
-
shutdown -r -F now
здесь ключ -F после перезагрузки системы принудительно запустит утилиту fsck на тщательную проверку файловых систем имеющихся разделов.
- King’s blog
- Добавить комментарий
- 18479 просмотров