LINUX.ORG.RU

Отключить или нет журналирование вот в чем вопрос.

 ,


0

1

Возник вопрос по поводу журналирования в ext4 ,а также процесса jbd2 .Суть такова при установке софта jbd2 загрузил IO винта на 98 % погуглил на эту тему выяснил что он так себя ведет у многих когда в системе появляется много новых маленьких файлов .Все бы ничего только висит в процессах и жует винт больно долго.У меня терпения хватило на полтора часа ,после чего я перезагрузился и jbd2 более не доставал. Меня мучает вопрос ,если так оно и должно быть то перезагрузкой я не дал ему проиндексировать файлы до конца и по логике он должен был продолжить их индексацию после перезагрузки.Но он молчит.Баг? Опять же нечто подобное было полгода назад, неужто за полгода не пофиксили? Знаю ,что если отключить с tune2fs журналирование jbd2 больше о себе не напоминает.А стоит ли игра свеч?
P.S. На форуме есть похожие темы ,но там один флейм и флуд.



Последнее исправление: SliFly (всего исправлений: 1)

по логике он должен был продолжить их индексацию после перезагрузки

Это еще почему? Тут не факт что файлы вообще на диск все попали из кэша. ФС была занята перестроением таблиц или что там у нее внутри, а ей бац по башке. При загрузке, если этот раздел не монтируется, то всем пофиг, пока он не используется, а если монтируется, то драйвер ФС должен сказать, что мол надо бы fsck тут запустить, а то мусор по углам раскидан, запчасти от файлов везде валяются и вообще. Короче после перезагрузки можно только fsck получить, но никак не «индексацию» или «продолжение банкета», потому что после удара по голове никто уже не помнит, чем он там занимался в прошлой жизни.

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

Kiborg ★★★
()
Ответ на: комментарий от Kiborg

Ок.Допустим ты это знаешь.А вот домохозяйка не обязана это знать. Разработчики это должны учитыватиь, ну или на крайняк выводить надпись: «эй ,слющай кнопку рэзэт не трогай,да? »

SliFly
() автор топика
Ответ на: комментарий от SliFly

Домохозяйка не обязана, и разработчики не обязаны. А надпись куда предлагаешь выводить? В консоль, в гуй, в логи? И как это реализовать?

Kiborg ★★★
()
Ответ на: комментарий от SliFly

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

anonymous
()

склоняюсь к мысли что это все таки тупо баг. Скорее всего эта тупая скотина не может найти какой то параметр и получается бесконечный цикл.

SliFly
() автор топика

быгыг слоупок.жыпег

у пионэров было можно запариваться по журналированию лет эдак 100 назад

нынче только бытыэрэфэс только хардкор

anonymous
()
Ответ на: комментарий от SliFly

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

Kiborg ★★★
()
7 июня 2015 г.

по поводу журналирования в ext4

Домашний юзер может смело отключать журнал. Это как использование ecc памяти, все знают о её пользе, но переплачивать?

Deleted
()
Ответ на: комментарий от Deleted

Да . Я отключил потому что затрахал jbd в иотоп 100%, временами . Не знаю почему разрабы ext такие слоупоки и не могут эту проблему пофиксить.Но уменя нет БП . Так что некоторые говорят , что при несанкционированной перезагрузке есть вероятность, что я увижу мешанину из файлов.И это напрягает. Но и терпеть мозготрахательный процесс jbd который факапит диск ,больше сил нет.

SliFly
() автор топика
Ответ на: комментарий от SliFly

Да . Я отключил потому что затрахал jbd в иотоп 100%, временами

Ну ок, ждём прохладную историю как твоя система развалилась после внезапного отключения электричества: когда через 10 часов fsck отработает и ты увидишь крошево в lost+found.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

прохладную историю
прохладная история

Это ты так пытаешься быть остроумным?

ТС пусть заюзает другую ФС. Тогда и прохладно не будет

Deleted
()
Ответ на: комментарий от no-such-file

система развалилась

OK. Допустим, катастрофа у SliFly произошла. Но означает ли это, что виновато отключение журнала? Нет. У него и до отключения журнала были предпосылки к проблемам (иотоп 100%, много мелких файлов на ext4). Журнал не предотвращает катастрофу. Воэможно он отсрочил бы проблемы, а может и нет. Так стоит ли ради гипотетического отсутствия проблем в будущем жертвовать настоящим (затрахал jbd ...)? А ведь есть еще бекапы.

anonymous
()
Ответ на: комментарий от anonymous

Но означает ли это, что виновато отключение журнала? Нет

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

no-such-file ★★★★★
()
Ответ на: комментарий от SliFly

что с ним делать чтоб он иотоп не забивал

С ним ничего не надо делать, надо найти какая скотина дёргает диск. Вангую, что это какая нибудь хренота, типа gvfsd-metadata, или strigi.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Ок. Вот сейчас я включу журналирование обратно. Через какое то время jbd сожрет как пиранья iotop , и как мне найти эту скотину, что стала тому причиной ? Каков алгоритм действий?

SliFly
() автор топика
Ответ на: комментарий от SliFly

Каков алгоритм действий?

Ну хотя бы сделать ps axl и посмотреть какие процессы сидят в состоянии D - ждут окончания ввода/вывода.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Окей попробую. Спасибо , что подсказал куда двигаться . Моя зрительная память еще подсказывает что в процессах iotop в этот момент сидел gvfsd-metadata в этот момент второй строчкой , но не постоянно , а периодически появляясь и занимая что то около пол мегабайта в секунду.

SliFly
() автор топика
Ответ на: комментарий от no-such-file

ты еще посоветуй кеширование отключить для сохранности данных

anonymous
()
Ответ на: комментарий от SliFly

Вот только не надо говорить то, о чем не знаете.

1. В 2001 году её портировали на линь, сама ФС старше как минимум на 7 лет

2. На сегодня действует её пятая реализация (v5), которая частично совместима с предыдущими реализациями (совместимость как между ext 2/3/4 примерно), так что говорить о её «старости» мягко говоря некоректно. Сейчас, это современная ФС с поддержкой кучи фич, некоторые из них, кстати, еще пару лет назад были только в ней

3. XFS изначально 64 битная ФС, в отличии от 32 битных ext2/3 и 48 битной ext4

З.Ы. Вы вот работаете на проце который от 386ого отличается фактически только инструкциями доролнительными, и при этом не спешите переходить на новые процессоррные архитектуры.

chaos_dremel ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.