Корректная проверка fsck

[Elimelech]

В файл /etc/rc.conf я добавил строки:

Код: Выделить всё

fsck_y_enable="YES"
background_fsck="NO"

При сбое и очередной загрузки запускается проверка, после чего через 3-5 секунд fsck пишет, что система чистая и продолжается нормальная загрузка.
Если это делать в ручном режиме, то проверка идет как надо, т.е долго минута-две
Правильно ли такое положение дел?

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[guest]

В файл /etc/rc.conf я добавил строки:

Код: Выделить всё

fsck_y_enable="YES"
background_fsck="NO"

При сбое и очередной загрузки запускается проверка, после чего через 3-5 секунд fsck пишет, что система чистая и продолжается нормальная загрузка.
Если это делать в ручном режиме, то проверка идет как надо, т.е долго минута-две
Правильно ли такое положение дел?

автоматический запуск fsck из init всегда будет быстрей чем ручной.

Все остальное зависит от типа созданной UFS2 и того что с ней произошло:

1) чистая UFS2 (без SU или SUJ) -> newfs /dev/adaXpY (GPT) или newfs /dev/adaXs[a-h] -> fsck_ffs -y
2) UFS2 + SU (SoftUpdate) -> newfs -U /dev/... -> fsck_ffs -y
3) UFS2 + SUJ (SoftUpdate + UFS2-Journaling) -> newfs -j -U /dev/... -> fsck_ffs -y

- вариант 1) - чистая UFS2, самая устойчивая, но самая медленная реализация, для нее достаточно в /etc/rc.conf:
#-- forced fsck-y
fsck_y_enable="YES"

- вариант 2) UFS2+SU, устойчивая и быстрая, что есть SU (SoftUpdate) - изучайте документацию, настройки rc.conf
аналогичные 1)

- вариант 3) UFS2+SUJ, неустойчивая и ненадежная, невзирая на реализацию журналирования, относительная
стабильность достигнута в 9.3 и 10.1 (для успешной работы, желательно наличие UPS), не позволяет
пока делать снапшоты и соответственно dump/restore на LiveRunningFS).
При отсутствии UPS, в /etc/rc.conf лучше использовать принудительную - полную проверку, невзирая на
журнал:

#-- forced fsck-y
fsck_y_enable="YES"
fsck_y_flags="-f"

При принудительной проверке : fsck_ffs -f - теряется смысл журналирования, при загрузке будет
ПОЛНАЯ проверка FS, без использования журанала, что для FS большого размера - большой промежуток времени!
Журнал позволяет использовать промежуточные состояния и за счет этого быстро исправлять ошибки без
полной (длительной) проверки всей FS:

журнал: состояние1 - состояние2 - ... - состояние N - состояние N+1 - сбой перезагрузка
проверка будет производится либо с состояния N+1 (описание утрированное "НА ПАЛЬЦАХ")

Без force в 9.0/9.1 - можно было потерять данные и нарваться на системный креш после падения
питания или при перезагрузке кнопками "Reboot" / "Off"

fsck_ffs -y отрабатывает исправления в соответствии с журналом, при этом на FS оставалось масса
ошибок и система выпадала в креш в конце или после загрузки.

fsck_ffs -f -y отрабатывает полную принудильную проверку FS.

Отсюда совет: если для корня используется отдельная FS размером 2-4GB, ни при каких условиях, не создавать
ее с SUJ. В SUJ еще долго будут вылавливать ошибки и проблемы.

Во всех вариантах, лучше дополнительно использовать:
#-- disable background fsck
background_fsck="NO"

[Elimelech]

спасибо за обширный ответ!

[snorlov]

Можно еще использовать geom_journal, другая разновидность журнала...

[Elimelech]

главное, чтобы оно стабильно работало