> а чем журнал то не угодил?тормоз он. Даже если не принимать во внимание "мой опыт" с автоприложившимся после падения битым журналом, превратившим почти исправную систему в полную кашу.
(сейчас в нем есть контроль целостности и барьеры, но это все добавляет тормозов, а осадочек после той истории остался)
Плюс лишняя ненужная для ssd нагрузка по записи. Плюс повышенная (из-за большего числа операций записи) вероятность попадания именно в момент, когда что-то пошло не так, ssd может очень нехорошо на это отреагировать.
А вот как раз fsck на нем занимает секунды, даже если какие-то странные ребята и живут еще на "десктопе" без ups. (у меня обычной причиной fsck является не пропадание питания, а крэш, и вот, честное слово, я не хочу в этом случае никакого автонаката журнала, нет там ничего суперценного в последних пяти секундах, а вот уже якобы-накаченное лучше бы перепроверить на логическую непротиворечивость. То есть правильное поведение - ровно обратное умолчаниям)
И да, я так живу и на обычных дисках тоже. Ровно с момента, когда вычитал, что гугль сапгрейдил свои хранилки именно на этот вариант (вырвав себе приличный клок волосьев с воплем "да хрен ли ж я сам-то не сообразил") - там с измеризмами и анализом потерь, можно, наверное, еще где-то найти. Потерь данных с тех пор не было (2010? Или 9). А, да, у меня еще и strictatime везде где можно, я хочу иметь возможность узнать, когда тут кто-то лазил до меня.
стандартный ext4 с журналом + lvm только за последний год успел дважды разнести в хлам базу svn (я уже даже выписал себе на бумажку алгоритм восстановления, там нифига неочевидно и непросто) - причем это технологический svn, запись в который происходит раз в неделю в лучшем случае, и никакой другой дисковой активности там нет (помимо обычного системного шлака, разумеется). Да, там отваливалась хранилка, но если у вас ничего никогда не отваливается, то зачем вам вообще журнал?
