zsx |
|
Темы:
1
Сообщения:
145
Участник с: 08 августа 2018
|
vasekПочему быть не может? Потому что корневой раздел не смонтирован? Через dmesg же можно прочитать сообщения о событиях до его монтирования. vasekЭто если с установочного это делать, похоже. После настройки через tune2fs у меня там не так. При проверке отражается прогресс, типа как в pacman, и если все хорошо, то подробностей нет. Да, и на linux-lts никаких "IGNORED" нет. Это с последним ядром. Жду следующего. ) |
sirocco |
|
Темы:
29
Сообщения:
2506
Участник с: 25 июля 2007
|
zsx У себя видел сообщения примерно такого вида (только на одной машине из трёх проверенных):
Причём это уже на lts ядре с fsck.mode=force (но до этого несколько недель использовалось ядро 4.19) Вылечил загрузкой с LiveUSB и прогоном в интерактивном режиме
Такие проблемы встречались у людей и раньше, так что может 4.19 и не виновато. Но на всякий случай перешёл на linux-lts https://unix.stackexchange.com/questions/392537/inode-extent-tree-at-level-1-could-be-shorter-ignored https://forum.manjaro.org/t/inode-extent-tree-could-be-narrower-ignored-message/48302 |
vasek |
|
Темы:
47
Сообщения:
11905
Участник с: 17 февраля 2013
|
zsxДелал при загрузке Arch с параметром break (или break=premount), после останова запускал fsck -vf /dev/sdaX EDIT 1 - кстати значение non-contiguous files (0,3%) в этом логе определяет уровень фрагментации файлов
Ошибки не исчезают с опытом - они просто умнеют
|
zsx |
|
Темы:
1
Сообщения:
145
Участник с: 08 августа 2018
|
В общем, можно сделать вывод, что корневой раздел лучше иногда проверять вручную и настройки ext4 по умолчанию лучше не трогать. Проверка диска запустится в любом случае после аварийного завершения работы системы, например. |
vasek |
|
Темы:
47
Сообщения:
11905
Участник с: 17 февраля 2013
|
siroccoПосмотрел свои записи о структуре ext4 и, насколько понял, ничего страшного нет, можно забить и это не связано с ядром, а связано со структурой экстентов (extent tree), типа сообщается, что на текущий момент уровень/глубина дерева экстентов меньше, чем была раньше и можно реструктуировать, если запустить e2fsk. Но не понятно, почему это не выполнилось автоматически? - может что то помешало? Вопрос в части использования опции -С 0 …….. e2fsck -C 0 /dev/sda1 Сколько ни читал раньше, смысл этой опции полностью не доходит, а потому никогда и не использую ..... а потому хочется уточнить EDIT 1 - насколько я понимаю "-C 0" это индикатор выполнения программы, хотя в man написано очень заумно ... а вот отрицательное, хрен поймешь ...
Ошибки не исчезают с опытом - они просто умнеют
|
zsx |
|
Темы:
1
Сообщения:
145
Участник с: 08 августа 2018
|
"-С 0" в tune2fs - это сброс счетчика монтирования корневого раздела (загрузок/перезагрузок системы). Имеет смысл только для планирования проверки. tune2fs -c 1 -C 0 /dev/sda1 - проверка при каждой загрузке. tune2fs -c 10 -C 0 /dev/sda1 - через каждые 10. Планирование хорошо само по себе, только можно не успеть или забыть прочитать сообщения при этом и в логах не найдешь. "-С 0" в e2fsck - отображение процесса на каждом этапе проверки. |
sirocco |
|
Темы:
29
Сообщения:
2506
Участник с: 25 июля 2007
|
https://bugzilla.kernel.org/show_bug.cgi?id=201685With 4.19.6, setting CONFIG_SCSI_MQ_DEFAULT=n seems to resolve the issue on my system, going back to CONFIG_SCSI_MQ_DEFAULT=y makes it show up again. Indeed all schedulers in /sys/devices/virtual/block/*/queue/scheduler are none. Насколько я понял, причина найдена, патч написан Jens Axboe. Т.е. проблема наблюдается при blk_mq (что стало по-умолчанию в ядре 4.19) и без планировщика -- [none] Кто-нибудь из посетителей форума рискнёт проверить? :) Не делайте этого без бекапа! (Установить mq [none] и запустить reproducer script) |
vall |
|
![]()
Темы:
45
Сообщения:
1786
Участник с: 28 марта 2017
|
Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19 (статья). |
sirocco |
|
Темы:
29
Сообщения:
2506
Участник с: 25 июля 2007
|
Выпущено ядро 4.19.8 с фиксом. |