ext4 и ядра 4.19

sirocco	# 3 года, 9 месяцев назад (отредактировано 3 года, 9 месяцев назад)
Темы: 29 Сообщения: 2501 Участник с: 25 июля 2007	У некоторых пользователей наблюдаются проблемы https://bbs.archlinux.org/viewtopic.php?id=242302 (первоначально была ссылка на не тот топик)

vasek	# 3 года, 9 месяцев назад
Темы: 48 Сообщения: 11322 Участник с: 17 февраля 2013	Предположу, что проблема связана с использованием (возможно и со чрезмерным использованием) расширенных аттрибутов. Согласно спецификации inode в конце индексного дескриптора создается область для размещения расширенных атрибутов (i_extra_isize). Но есть один нюанс - если эта область переполняется, то выделятся другой блок … и имхо, чем сложнее, тем больше проблем.... возможно проблема в этом. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 3 года, 9 месяцев назад

Темы: 48

Сообщения: 11322

Участник с: 17 февраля 2013

Предположу, что проблема связана с использованием (возможно и со чрезмерным использованием) расширенных аттрибутов.
Согласно спецификации inode в конце индексного дескриптора создается область для размещения расширенных атрибутов (i_extra_isize). Но есть один нюанс - если эта область переполняется, то выделятся другой блок … и имхо, чем сложнее, тем больше проблем.... возможно проблема в этом.

Ошибки не исчезают с опытом - они просто умнеют

zsx	# 3 года, 9 месяцев назад
Темы: 1 Сообщения: 145 Участник с: 08 августа 2018	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"в процессе загрузки. В логах на эту тему пусто.

zsx

# 3 года, 9 месяцев назад

Темы: 1

Сообщения: 145

Участник с: 08 августа 2018

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"в процессе загрузки. В логах на эту тему пусто.

zsx	# 3 года, 9 месяцев назад (отредактировано 3 года, 9 месяцев назад)
Темы: 1 Сообщения: 145 Участник с: 08 августа 2018	Тут, похоже, еще надо сказать вот о чем. В процессе загрузки пока еще не очень настроенной системы мы все видим 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

# 3 года, 9 месяцев назад (отредактировано 3 года, 9 месяцев назад)

Темы: 1

Сообщения: 145

Участник с: 08 августа 2018

Тут, похоже, еще надо сказать вот о чем. В процессе загрузки пока еще не очень настроенной системы мы все видим 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-ой перезагрузки, когда непосредственно и будет выполнена проверка.

Проверьте у себя данные параметры. А то может оказаться иллюзия проверки файловой системы.

Lupo_Alberto	# 3 года, 9 месяцев назад (отредактировано 3 года, 9 месяцев назад)
Темы: 10 Сообщения: 110 Участник с: 08 сентября 2013	zsx Проверьте у себя данные параметры. А то может оказаться иллюзия проверки файловой системы. А насколько важна проверка журналируемых файловых систем? В man tune2fs написано, что полностью рассчитывать на журнал не сто́ит, но хотелось бы услышать мнение форумчан. Как я понимаю, проводить ручную проверку на смонтированной файловой системе небезопасно. Как поступить в случае необходимости её проверки? Единственное, что сразу пришло на ум — загрузиться с «живого» диска.

Lupo_Alberto

# 3 года, 9 месяцев назад (отредактировано 3 года, 9 месяцев назад)

Темы: 10

Сообщения: 110

Участник с: 08 сентября 2013

zsx
Проверьте у себя данные параметры. А то может оказаться иллюзия проверки файловой системы.

А насколько важна проверка журналируемых файловых систем?
В man tune2fs написано, что полностью рассчитывать на журнал не сто́ит, но хотелось бы услышать мнение форумчан.
Как я понимаю, проводить ручную проверку на смонтированной файловой системе небезопасно.
Как поступить в случае необходимости её проверки? Единственное, что сразу пришло на ум — загрузиться с «живого» диска.

vasek	# 3 года, 9 месяцев назад (отредактировано 3 года, 9 месяцев назад)
Темы: 48 Сообщения: 11322 Участник с: 17 февраля 2013	Мое мнение Мы же доверяем разработчикам, считаем их не глупыми и пользуемся ихними разработками, а значит должны доверять значениям параметров, установленных ими по умолчанию - они эти параметры установили не просто так, а на основе анализа и ориентировались на среднего пользователя. Менять эти значения, установленные разработчиками по умолчанию, нужно только в том случае, если пользователь понимает к чему это приведет и уверен, что это необходимо. В данном конкретном случае значения файловой системы, установленные по умолчанию # 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 Ошибки не исчезают с опытом - они просто умнеют

vasek

# 3 года, 9 месяцев назад (отредактировано 3 года, 9 месяцев назад)

Темы: 48

Сообщения: 11322

Участник с: 17 февраля 2013

Мое мнение
Мы же доверяем разработчикам, считаем их не глупыми и пользуемся ихними разработками, а значит должны доверять значениям параметров, установленных ими по умолчанию - они эти параметры установили не просто так, а на основе анализа и ориентировались на среднего пользователя. Менять эти значения, установленные разработчиками по умолчанию, нужно только в том случае, если пользователь понимает к чему это приведет и уверен, что это необходимо.
В данном конкретном случае значения файловой системы, установленные по умолчанию
# 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

Ошибки не исчезают с опытом - они просто умнеют

zsx	# 3 года, 9 месяцев назад
Темы: 1 Сообщения: 145 Участник с: 08 августа 2018	Lupo_Alberto А насколько важна проверка журналируемых файловых систем? Исходя из https://wiki.archlinux.org/index.php/Ext4, иногда рекомендуется не только проверка, но и дефрагментация. Lupo_Alberto Как я понимаю, проводить ручную проверку на смонтированной файловой системе небезопасно. Естественно. Насколько я понимаю, проверка корневого раздела при загрузке системы проводится до его монтирования, иначе такой возможности не было бы предусмотрено. Если это не так, то кроме мата на ум ничего не приходит.

zsx

# 3 года, 9 месяцев назад

Темы: 1

Сообщения: 145

Участник с: 08 августа 2018

Lupo_Alberto
А насколько важна проверка журналируемых файловых систем?

Исходя из https://wiki.archlinux.org/index.php/Ext4, иногда рекомендуется не только проверка, но и дефрагментация.

Lupo_Alberto
Как я понимаю, проводить ручную проверку на смонтированной файловой системе небезопасно.

Естественно. Насколько я понимаю, проверка корневого раздела при загрузке системы проводится до его монтирования, иначе такой возможности не было бы предусмотрено. Если это не так, то кроме мата на ум ничего не приходит.

nafanja	# 3 года, 9 месяцев назад (отредактировано 3 года, 9 месяцев назад)
Темы: 94 Сообщения: 9252 Участник с: 02 июня 2012 заблокирован	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

# 3 года, 9 месяцев назад (отредактировано 3 года, 9 месяцев назад)

Темы: 94

Сообщения: 9252

Участник с: 02 июня 2012

заблокирован

vasek
Проверку можно выполнить, загрузившись с параметром загрузки break или break=premount (останов загрузки до монтирования файловой системы) и по рекомендации Wiki «To automatically repair damaged portions, run: fsck -a »

уточню, break сработает если не используется хук systemd в mkinitcpio.conf

Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874

vasek	# 3 года, 9 месяцев назад
Темы: 48 Сообщения: 11322 Участник с: 17 февраля 2013	nafanja break сработает если не используется хук systemd в mkinitcpio.conf читал об этом, но не проверял, так как никогда не использую хук systemd. И еще, я в основном использую break=premount, который, насколько понимаю, вроде бы сработает с хуком systemd - хотя не уверен, не проверял. Если у тебя стоит этот хук, проверь (не хочется редактировать ...) Ошибки не исчезают с опытом - они просто умнеют

vasek

# 3 года, 9 месяцев назад

Темы: 48

Сообщения: 11322

Участник с: 17 февраля 2013

nafanja
break сработает если не используется хук systemd в mkinitcpio.conf

читал об этом, но не проверял, так как никогда не использую хук systemd.
И еще, я в основном использую break=premount, который, насколько понимаю, вроде бы сработает с хуком systemd - хотя не уверен, не проверял.
Если у тебя стоит этот хук, проверь (не хочется редактировать ...)

Ошибки не исчезают с опытом - они просто умнеют

nafanja	# 3 года, 9 месяцев назад
Темы: 94 Сообщения: 9252 Участник с: 02 июня 2012 заблокирован	vasek Если у тебя стоит этот хук, проверь (не хочется редактировать …) да, я его очень давно использую... проверял... не работает... Псевдографический инсталлятор Arch Linux ver. 3.8.2 Благодарности принимаются на ЯД 410012815723874