ext4 и ядра 4.19

У некоторых пользователей наблюдаются проблемы

https://bbs.archlinux.org/viewtopic.php?id=242302

(первоначально была ссылка на не тот топик)
Предположу, что проблема связана с использованием (возможно и со чрезмерным использованием) расширенных аттрибутов.
Согласно спецификации inode в конце индексного дескриптора создается область для размещения расширенных атрибутов (i_extra_isize). Но есть один нюанс - если эта область переполняется, то выделятся другой блок … и имхо, чем сложнее, тем больше проблем.... возможно проблема в этом.
Ошибки не исчезают с опытом - они просто умнеют
sirocco
https://bbs.archlinux.org/viewtopic.php?id=242302

There is an obscure ext4 fs corruption on 4.19 kernels currently worked on. It is still unclear if ths is a bug in the ext4 driver itself or due to something else. I personally suspect the latter.
In the meantime, I suggest you to switch to the lts kernel waiting for the developers to investigate further.

Непосредственно по поводу fsck могу подтвердить, что на lts всё гладко, а на 4.19 при проверке корневого раздела мельком видел какие-то сообщения fsck со словом "IGNORED"в процессе загрузки. В логах на эту тему пусто.
Тут, похоже, еще надо сказать вот о чем. В процессе загрузки пока еще не очень настроенной системы мы все видим fsck messages типа
/dev/sda1: clean, 201776/60878736 files, 4991277/243040256 blocks

Прочитав Wiki,
By default, fsck checks a filesystem every 30 boots (counted individually for each partition)
можно подумать, что дополнительные настройки нам здесь и не нужны.
Но что-то я не видел раньше кроме вышеупомянутого никаких других сообщений о проверке корневого раздела, не смотря на fsck hook по умолчанию.
Посмотрев параметры ext4...
# tune2fs -l /dev/sda1
...обнаружилось, что в опции Mount count: большое число, а в опции Maximum mount count: прочерк. То есть проверка даже не запланирована.

Включить проверку через каждые 30 загрузок системы можно так:
# tune2fs -c 30 -C 0 /dev/sda1
И вы увидите уже немного другие fsck messages с обратным отсчетом до 30-ой перезагрузки, когда непосредственно и будет выполнена проверка.

Проверьте у себя данные параметры. А то может оказаться иллюзия проверки файловой системы.
zsx
Проверьте у себя данные параметры. А то может оказаться иллюзия проверки файловой системы.
А насколько важна проверка журналируемых файловых систем?
В man tune2fs написано, что полностью рассчитывать на журнал не сто́ит, но хотелось бы услышать мнение форумчан.
Как я понимаю, проводить ручную проверку на смонтированной файловой системе небезопасно.
Как поступить в случае необходимости её проверки? Единственное, что сразу пришло на ум — загрузиться с «живого» диска.
Мое мнение
Мы же доверяем разработчикам, считаем их не глупыми и пользуемся ихними разработками, а значит должны доверять значениям параметров, установленных ими по умолчанию - они эти параметры установили не просто так, а на основе анализа и ориентировались на среднего пользователя. Менять эти значения, установленные разработчиками по умолчанию, нужно только в том случае, если пользователь понимает к чему это приведет и уверен, что это необходимо.
В данном конкретном случае значения файловой системы, установленные по умолчанию
# tune2fs -l /dev/sda3
Maximum mount count:      -1
Check interval:           0 (<none>)
и, насколько я понимаю, это означает, что проверка fsck автоматически выполняться не будет. Проверка fsck будет выполнена только в том случае если файловая система была размонтирована/смонтирована с ошибками, в более тяжелом случае система выдаст сообщение, что при монтировании имеются проблемы и нужно выполнить проверку fsck.
И думаю это логично, зачем запускать fsck, если для этого нет причин.
Как следует из вывода последняя проверка у меня была выполнена в 2017г.
Last checked:             Thu Aug  3 13:17:21 2017
Плюс к этому в выводе имеется также и заключение о состоянии системы
Filesystem state:         clean

Lupo_Alberto
Как я понимаю, проводить ручную проверку на смонтированной файловой системе небезопасно.
Как поступить в случае необходимости её проверки? Единственное, что сразу пришло на ум — загрузиться с «живого» диска.
Проверку можно выполнить, загрузившись с параметром загрузки break или break=premount (останов загрузки до монтирования файловой системы) и по рекомендации Wiki «To automatically repair damaged portions, run: fsck -a » лучше по старинке, с опцией -f
Ошибки не исчезают с опытом - они просто умнеют
Lupo_Alberto
А насколько важна проверка журналируемых файловых систем?
Исходя из https://wiki.archlinux.org/index.php/Ext4, иногда рекомендуется не только проверка, но и дефрагментация.

Lupo_Alberto
Как я понимаю, проводить ручную проверку на смонтированной файловой системе небезопасно.
Естественно. Насколько я понимаю, проверка корневого раздела при загрузке системы проводится до его монтирования, иначе такой возможности не было бы предусмотрено. Если это не так, то кроме мата на ум ничего не приходит.
vasek
Проверку можно выполнить, загрузившись с параметром загрузки break или break=premount (останов загрузки до монтирования файловой системы) и по рекомендации Wiki «To automatically repair damaged portions, run: fsck -a »
уточню, break сработает если не используется хук systemd в mkinitcpio.conf
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
break сработает если не используется хук systemd в mkinitcpio.conf
читал об этом, но не проверял, так как никогда не использую хук systemd.
И еще, я в основном использую break=premount, который, насколько понимаю, вроде бы сработает с хуком systemd - хотя не уверен, не проверял.
Если у тебя стоит этот хук, проверь (не хочется редактировать ...)
Ошибки не исчезают с опытом - они просто умнеют
vasek
Если у тебя стоит этот хук, проверь (не хочется редактировать …)
да, я его очень давно использую... проверял... не работает...
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
 
Зарегистрироваться или войдите чтобы оставить сообщение.