Ext4 такая ext4

man fsync

научись читать.

Не, можно требовать хранения старых данных, которые были записаны ДО прошлого sync'а и не тронуты после него. Можно потребовать, что новые записи были отменены, если они не были завершены. Но требовать что-бы всё правильно было сделано в момент этого sync'а - думаю нельзя.

вот этого все и хотят тут :). Это и обсуждаем.

тогда расскажите, КОГДА был последний sync? Я думаю - хрен его знает. Может месяц назад, а может и год.

никто тут не требует :).

да, но если на каждом байте sync'ать, как это выше предлагали, то - нужно требовать.

не, наоборот, пусть чаще маленькими кусками накатывает транзакции (или что там) чтобы минимизировать повреждения.

вот именно! пусть накатывает часто и по чуть-чуть. Только момент наката тогда должен быть устойчивым к сбою.

надо спеки хардов посмотреть для интереса...

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

научись читать.

Доо.

Если пропало питание то всё что уже записалось никуда не денется.

о каких гарантиях ты говоришь? Что-бы всё _гарантированно_ записалось, нужно syncнуть раздел, а лучше вообще размонтировать. Тогда его можно безопасно(для данных) отключить

Это тебе нужно маны читать.

Это тебе нужно маны читать.

можно цитатку, о том, что в момент sync'а можно обесточить систему, и всё будет хорошо? я в man'е не нашёл... Нашёл, что ПОСЛЕ sync все данные, которые были в памяти ДО sync'а будут гарантированно записаны. Но это совсем не то, о чём я писал.

можно цитатку, о том, что в момент sync'а можно обесточить систему, и всё будет хорошо? я в man'е не нашёл

Потому что в мане ее нет. Если ты подумаешь о том, как определить понятие «в момент sync», ты поймешь, почему ее там нет.

Нашёл, что ПОСЛЕ sync все данные, которые были в памяти ДО sync'а будут гарантированно записаны. Но это совсем не то, о чём я писал.

Да, ты писал о том, что нужно sync-нуть или размонтировать _раздел_, а этого не нужно - достаточно sync-нуть _файл_. Так что «_гарантированный_ способ сохранения файлов» есть, даже 2 способа.

Потому что в мане ее нет. Если ты подумаешь о том, как определить понятие «в момент sync», ты поймешь, почему ее там нет.

очевидно, это время исполнения данной команды. ну запиши что-нить на флешку, и сделай sync, увидишь невооружённым глазом.

Да, ты писал о том, что нужно sync-нуть или размонтировать _раздел_, а этого не нужно - достаточно sync-нуть _файл_.

ты сам man прочитай что-ли? где ты видел sync file??? sync'ать можно только ФС. (в т.ч. и функцией syncfs(2))

Если ты про fsync(2), то к процессу отложенной записи это не имеет отношения. Ты просто сбрасываешь в ФС внутренний буфер потока (который FILE*). В данном случае про sync(2) речи нет, этот буфер сбрасывается не на диск, а в файловый кеш.

Так что «_гарантированный_ способ сохранения файлов» есть, даже 2 способа.

есть гарантированный способ отправки ВСЕГО файлового кеша на диск. Вот только этот кеш может занимать сотни, и даже тысячи мегабайт, а диск может быть очень медленным. Потому этот процесс может растянутся надолго. И никто тебе не даст гарантии, что всё будет хорошо. Я тебе больше скажу, если прервать sync(2) посередине, то половина данных будет записана, а вторая половина - нет. Возми флешку, и попробуй поэкспериментировать, прежде чем отсылать меня в маны. Я оттуда не выхожу ваще-то.

Если ты подумаешь о том, как определить понятие «в момент sync», ты поймешь, почему ее там нет.

очевидно, это время исполнения данной команды

sync(2) делает sync(3). Ты спрашиваешь, запишутся ли данные на момент исполнения sysenter? А ведь sysenter - это уже «время выполнения sync». %)

Да, ты писал о том, что нужно sync-нуть или размонтировать _раздел_, а этого не нужно - достаточно sync-нуть _файл_.

ты сам man прочитай что-ли? где ты видел sync file???

fsync(2), если ты не понял.

Если ты про fsync(2), то к процессу отложенной записи это не имеет отношения. Ты просто сбрасываешь в ФС внутренний буфер потока (который FILE*)

Мде. Ты хоть видел прототип fsync? Там тупо нет FILE *:

int fsync(int fd);

Так что «_гарантированный_ способ сохранения файлов» есть, даже 2 способа.

есть гарантированный способ отправки ВСЕГО файлового кеша на диск.

А еще есть гарантированный способ отправки кэша, принадлежащего ровно одному файлу. Это, внезапно, fdatasync(2)

sync(2) делает sync(3).

вот man 3 sync у мну нет. Делись.

Ты спрашиваешь, запишутся ли данные на момент исполнения sysenter?

нет, не спрашиваю. А надо?

Мде. Ты хоть видел прототип fsync? Там тупо нет FILE *:

а, ну да. Там дескриптор. Всё равно, причём тут sync(2)?

А еще есть гарантированный способ отправки кэша, принадлежащего ровно одному файлу. Это, внезапно, fdatasync(2)

ну причём тут это-то?

Сам подумай, каким образом ты можешь слить на диск данные только одного файла, если тебе по крайне мере придётся слить хотя-бы суперблок?

Да и вообще, причём тут это? Повторяю, я говорил о том, что sync - долгая операция. И она попросту не может быть атомарной. Да, после её завершения всё будет гарантированно записано, но что будет записано посередине - нигде не определено.

вот man 3 sync у мну нет

http://linux.die.net/man/3/sync

А еще есть гарантированный способ отправки кэша, принадлежащего ровно одному файлу. Это, внезапно, fdatasync(2)

ну причём тут это-то?

При том, что кудрявые способы типа «отмонтировать раздел» не нужны.

Сам подумай, каким образом ты можешь слить на диск данные только одного файла,

Это забота авторов ФС, не моя. Единственное, что мне нужно знать - после fdatasync данные записаны на поверхность диска.

если тебе по крайне мере придётся слить хотя-бы суперблок?

Замени «суперблок» на «служебные структуры», и твоя фраза будет правдоподобной.

Хотя fdatasync, не изменяющий размеров файла, служебных данных затрагивать не должен.

Повторяю, я говорил о том, что sync - долгая операция. И она попросту не может быть атомарной.

Зависит от определения атомарности (журналируемые ФС вполне могут сделать ее атомарной). Но даже если нет журналируемой ФС, даже если сектор записан наполовину - ведение логов СУБД рассчитано на это. В журнале просто не будет одной транзакции.

http://linux.die.net/man/3/sync

у тебя вообще Linux? Если да, то читай:

BUGS According to the standard specification (e.g., POSIX.1-2001), sync() schedules the writes, but may return before the actual writing is done. However, since version 1.3.20 Linux does actually wait. (This still does not guarantee data integrity: modern disks have large caches.)

так то. даже Linux'овая sync(2) НЕ гарантирует записи данных на диск. А твоя sync(3) дык вообще ни о чём.

При том, что кудрявые способы типа «отмонтировать раздел» не нужны.

если тебе не нужны гарантии, то дело твоё.

Это забота авторов ФС, не моя. Единственное, что мне нужно знать - после fdatasync данные записаны на поверхность диска.

а обеспечить бесперебойное питание во время выполнения fdatasync(2) чья задача? Может Чубайса?

Хотя fdatasync, не изменяющий размеров файла, служебных данных затрагивать не должен.

кто сказал, что размер не изменяется?

Зависит от определения атомарности (журналируемые ФС вполне могут сделать ее атомарной)

могут. Если питание не пропадёт. А мы как раз и рассматриваем случай аппаратного сбоя, а не софтового. Это если ты забыл.

Но даже если нет журналируемой ФС, даже если сектор записан наполовину - ведение логов СУБД рассчитано на это.

конечно рассчитано. Но опять-таки, в предположении, что у юзера не сядет батарейка. А у ТСа она таки села.

Давайте тогда сразу после блэкаута делать mkfs

дык так и делаем

Зачем тогда тебе fsck и журналы? Без журналов производительность ФС гораздо выше будет.

а чего ты взял, что структура файла (в т.ч. журнала) _линейна на диске_?

Журнал не является файлом.

Ты думаешь, там всё просто так подряд и пишется, как во времена магнитных барабанов?

Да.

Хочешь сказать, что это не баг и не неисправность аппаратуры, а именно by design?

именно так. такие вот хреновые у нас HDD. Ничего не поделать...

Пруфлинк.

Без журналов производительность ФС гораздо выше будет.

пруф? по моим измерениям от журналирования производительность не сильно страдает. Я пробовал журнал отключить.

Журнал не является файлом.

ORLY?

Ты думаешь, там всё просто так подряд и пишется, как во времена магнитных барабанов?

Да.

ну тогда и разговаривать собственно не о чем.

а обеспечить бесперебойное питание во время выполнения fdatasync(2) чья задача? Может Чубайса?

Наблюдаю полное непонимание принципа журналирования. И отсутствие желания понять.

Пруфлинк.

пруф чего? того, что даже sync не даёт гарантии сброса кеша на диск, и таким образом мы не можем гарантировать корректное завершение записи при некорректном отключении?

повторяю:

BUGS According to the standard specification (e.g., POSIX.1-2001), sync() schedules the writes, but may return before the actual writing is done. However, since version 1.3.20 Linux does actually wait. (This still does not guarantee data integrity: modern disks have large caches.)

man 2 sync

Наблюдаю полное непонимание принципа журналирования. И отсутствие желания понять.

разъяснить сирым и убогим религия не позволяет?

Журнал не является файлом.

ORLY?

YA RLY. К примеру, в reiserfs3.6 в суперблоке есть указание, откуда и докуда журнал лежит. Обязательно одним куском. Как файл он не значится. В ext3 таки да, был файл, но тоже сплошной. В ext4 не смотрел.

modern disks have large caches

hdparm -W 0 /dev/sdX

Кстати, в каких-то мануалах по настройке баз данных видел.

пруф чего?

Охренеть. Ты вообще читаешь ту ветку разговора, в которую влезаешь? Давай я специально для тебя её выпишу:

Т.е. ты никогда не встречал сообщений о сильном повреждении ФС после выключения питания, когда даже fsck не помогает?

Хочешь сказать, что это не баг и не неисправность аппаратуры, а именно by design?

именно так. такие вот хреновые у нас HDD. Ничего не поделать...

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

разъяснить сирым и убогим религия не позволяет?

К чему пафос? Я объясню, если слушать будешь. Запись происходит в несколько заходов. Когда ФС осознаёт, что пора на диск писать (мета)данные, формируется структура транзакции. В ней есть уникальный идентификатор и собственно данные. Конкретно в reiserfs у транзакции есть desc block и commit block, между ними данные.

1. на диск пишутся desc и блоки данных транзакции
2. sync
3. пишется commit block
4. sync
5. данные пишутся в область данных (туда, куда они предназначались)
6. sync
7. в заголовке журнала отмечается, что транзакция прошла (увеличивается счётчик)

Теперь про сбои. Если сбой произошёл до того как завершились 1 и 2, ничего не происходит. (Мета)данные не менялись, всё отлично, ничего не делаем. Если сбой произошёл до завершения 3 и 4, транзакция не считается корректной, (мета)данные не менялись, всё отлично, ничего не делаем. Если сбой произошёл до завершения 5 и 6 — беда, (мета)данные записаны частично, ФС повреждена. Тогда мы смотрим в журнал, видим, что после последней прошедшей транзакции в журнале есть ещё несколько. Пишем их данные на диск, отмечаем их успешно прошедшими. (Мета)данные снова в непротиворечивом состоянии. Если вдруг между 6 и 7 произошёл сбой и транзакции остались неподтверждёнными, ничего страшного — при монтировании неподтверждённые будут проиграны заново. Фактически будут писаться те же (мета)данные.

Журнал не является файлом.

Как минимум в ext3 журнал - это такой же inode, как и у обычного файла.

Журнал не является файлом.

ORLY?

https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Journal_.28jbd2.29

Introduced in ext3, the ext4 filesystem employs a journal to protect the filesystem against corruption in the case of a system crash. A small continuous region of disk (default 128MiB) is reserved inside the filesystem as a place to land «important» data writes on-disk as quickly as possible.

Немного не похоже на нормальный файл, да?

Как минимум в ext3 журнал - это такой же inode, как и у обычного файла.

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

так то. даже Linux'овая sync(2) НЕ гарантирует записи данных на диск.

Кэши на дисках давно уже управляемые; sync «не гарантирует целостности» только в том смысле, что не останавливает активность в системе.

А твоя sync(3) дык вообще ни о чём.

Если ты не понял, sync(2) - это просто вызов sync(3) %)

При том, что кудрявые способы типа «отмонтировать раздел» не нужны.

если тебе не нужны гарантии, то дело твоё.

Если отмонтирование раздела - единственный способ гарантированной записи файла, который ты знаешь, то это дело твое.

обеспечить бесперебойное питание во время выполнения

кто сказал, что размер не изменяется?

Это не задача вообще.

Хотя fdatasync, не изменяющий размеров файла, служебных данных затрагивать не должен.

кто сказал, что размер не изменяется?

Не тупи.

Зависит от определения атомарности (журналируемые ФС вполне могут сделать ее атомарной)

могут. Если питание не пропадёт.

Для журналируемых ФС пропадание питания - это штатный сбой, который они корректно обрабатывают by design. В ext3 атомарность обеспечивается накатом журнала во время монтирования.

Но даже если нет журналируемой ФС, даже если сектор записан наполовину - ведение логов СУБД рассчитано на это.

конечно рассчитано. Но опять-таки, в предположении, что у юзера не сядет батарейка.

Ведение журнала СУБД расчитано и на работу при сбоях питания.

Наличие inode не делает журнал обыкновенным файлом.

inode тянет за собой все структуры, имеющиеся у обычного файла, более того, у него может быть и имя. Если этого мало - что делает некий файл «обыкновенным»?

В ext3 таки да, был файл, но тоже сплошной. В ext4 не смотрел.

сплошной с т.з. ФС. Что там на диске - неизвестно. В EXT4 тоже самое.

hdparm -W 0 /dev/sdX Кстати, в каких-то мануалах по настройке баз данных видел.

то, что кеш можно отключить вовсе не доказывает, что он отключён. Ты не поверишь, но отключён он _очень_ редко. А надёжность БД достигается обычно иными путями (репликация, те же бекапы).

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

это не «часть дизайна», это текущее положение дел. Такие у нас сегодня HDD и такие у нас сегодня FS. Просто сейчас _дешевле_ сделать бесперебойное питание, чем подставлять под него костыли, а потом мучительно долго всё восстанавливать. К тому же, пропадание питания - не единственное, что приводит к нарушению структуры и целостности данных. Именно потому, разрабы дисков и ФС не сильно заботятся об этом. Можешь называть это «дизайном», если так нравится.

Что там на диске - неизвестно.

Никак в толк не возьму, что ты пытаешься доказать? Какой-то фатализм и «спор ради спора».

inode тянет за собой все структуры, имеющиеся у обычного файла, более того, у него может быть и имя. Если этого мало - что делает некий файл «обыкновенным»?

Обыкновенным его делает способ его использования. Скажем, S_ISREG() не считает директорию или символическую ссылку обыкновенными. Хотя inode у них имеется.

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

Скажем, S_ISREG() не считает директорию или символическую ссылку обыкновенными. Хотя inode у них имеется.

S_ISREG считает .journal обычным файлом.

Еще раз: способ использования журнала радикально отличается от способа использования обыкновенных файлов.

Так можно договориться до того, что «обыкновенных» файлов вообще не существует. Единственным серьезным отличием .journal от созданных пользователем файлов - то, что в него пишет сама ФС. Но по всем остальным параметрам - это вполне обычный файл.

Я объясню, если слушать будешь. Запись происходит в несколько заходов.

тебе не кажется, что ТРИ sync'а на КАЖДУЮ запись это довольно много? Я полностью согласен с тем, что при такой записи вполне можно всё откатить, но разве это применяется на практике? Не знаю как в reiser, но в EXT3,4 по умолчанию, такого нет.

К чему пафос?

к тому, что я в курсе, как _должна_ работать журналируемая ФС. А теперь открой даташит на свой винт, и посмотри, _сколько_ времени нужно, что-бы сдвинуть головки от дорожки с данными, до дорожки с журналом, и до дорожки заголовка. А потом обратно. Или у тебя есть отддельный диск для журнала? Нету?

Теперь про сбои.

давай про сбои IRL: как происходит изменение файла X? Очень просто:

1. создаётся временный файл в том же каталоге (например Y)
2. обработанное содержимое X копируется в Y
3. файл Y переименовывается в X, и одновременно X уничтожается (или переименовывается в X~)

Очевидно, что если операция №3 атомарна (а она атомарна), то на любой ФС всё будет хорошо. Даже на FAT. Но НЕ на хорошей журналируемой ФС. На хорошей журналируемой ФС мы имеем отложенную запись и журнал одновременно. Отложенная запись приводит к тому, что мы имеем _одновременно_ два файла X (потому-что операция №2 откладывается, и завершается ПОСЛЕ операции №3). При этом старый файл X непротиворечив, а вот новый файл X недоделан ещё. Что произойдёт, если случится сбой? Всё очень просто - ФС восстановит последние непротиворечивое состояние файла X. А это состояние соответствует тому моменту, когда новый файл X был только-что создан (потом на него непрерывна шла запись старого X, и состояние его было противоречивым)

В итоге, мы и наблюдаем это удивительное обнуление файлов. Хотя если вдуматься, ничего удивительного тут нет, ФС всё правильно сделала. А что ей оставалось? Восстановить вчерашний старый X? А почему не позавчерашний? Она последний восстановила, в его единственном непротиворечивом состоянии. Чем вы недовольны? Журналирование прекрасно сработало.

Немного не похоже на нормальный файл, да?

никто здесь не говорил, что журнал, это обычный регулярный файл. Конечно, обычно это специальный файл, для которого выделенно специальное место. Но тем не менее, это таки файл. Во всяком случае в EXT2,3,4.

Немного не похоже на нормальный файл, да?

Оттуда же: the journal itself is normal (but hidden) file within the filesystem.

Никак в толк не возьму, что ты пытаешься доказать?

то, что аппаратный сбой не лечится в общем случае никаким журналированием. А аварийное отключение питания == аппаратный сбой.

тебе не кажется, что ТРИ sync'а на КАЖДУЮ запись это довольно много?

Говорят, достаточно одного, но там сложнее доказательство, и я его не понимаю.

к тому, что я в курсе, как _должна_ работать журналируемая ФС. А теперь открой даташит на свой винт, и посмотри, _сколько_ времени нужно, что-бы сдвинуть головки от дорожки с данными, до дорожки с журналом, и до дорожки заголовка. А потом обратно. Или у тебя есть отддельный диск для журнала? Нету?

Океюшки. Только вопрос о производительности я вообще не поднимал. Так что это не ко мне. Я говорил про журналирование, а ты про fsync и почему он не даёт гарантий. Тебе рассказали, что гарантии даёт журнал, но ты не выявил понимания вопроса, продолжая спекулировать выключением питания во время fsync.

Теперь про гарантии. Как известно, 100%-ных гарантий быть не может в принципе. Так мир устроен, всё шумит, особенно на современных плотностях. Вспомни про hardware recovered ECC и его порядки. Да там чуть ли не каждое чтение идёт с ошибкой. И вероятность того, что «корректный результат» ECC восстановит исходные данные, не равна 100%.

то, что аппаратный сбой не лечится в общем случае никаким журналированием. А аварийное отключение питания == аппаратный сбой.

А его задача не дать 100%-ные гарантии, а увеличить вероятность восстановления непротиворечивого состояния. Тебя не пугает дедупликация в zfs? Блоки сливаются если их хэши совпадают. Но ведь есть 2^(-256) шанс, что блоки будут разные. Просто на такую вероятность всем плевать. Вот и с журналом так.

Единственным серьезным отличием .journal от созданных пользователем файлов - то, что в него пишет сама ФС.

Важно то, что ФС обращается с ним совершенно особенным образом. Есть у него при этом inode или нету - это уже незначительная мелочь.

А аварийное отключение питания == аппаратный сбой.

Ты бредишь.

Важно то, что

...твое понятие о «нормальности» отличается и от понятия Вики Ext4, и от обычного здравого смысла.

S_ISREG считает .journal обычным файлом.

Что-то не вижу я его:

# mount | grep ext4
/dev/sda2 on / type ext4 (rw,relatime,data=ordered)
/dev/sda3 on /home type ext4 (rw,relatime,data=ordered)

# find / -mount | grep journal
/lib/systemd/system/systemd-journald.socket
/lib/systemd/system/sockets.target.wants/systemd-journald.socket
/lib/systemd/system/sysinit.target.wants/systemd-journald.service
/lib/systemd/system/systemd-journald.service
/lib/systemd/systemd-journald
/var/log/journal
/var/log/journal/99e6abcaae5439c466a47d27000009bd
/var/log/journal/99e6abcaae5439c466a47d27000009bd/system.journal
/var/log/journal/99e6abcaae5439c466a47d27000009bd/user-1000.journal
/etc/systemd/systemd-journald.conf
/bin/systemd-journalctl
/usr/lib/pm-utils/power.d/journal-commit
/usr/sbin/named-journalprint
/usr/share/man/man8/named-journalprint.8.gz
/usr/share/man/man5/systemd-journald.conf.5.gz
/usr/share/man/man1/systemd-journalctl.1.gz
/usr/share/locale-bundle/en_GB/LC_MESSAGES/gnome-activity-journal.mo
/usr/share/locale-bundle/ru/LC_MESSAGES/gnome-activity-journal.mo
/usr/share/locale-bundle/en_AU/LC_MESSAGES/gnome-activity-journal.mo
/usr/lib64/libsystemd-journal.so.0.0.3
/usr/lib64/libsystemd-journal.so.0

...твое понятие о «нормальности» отличается и от понятия Вики Ext4, и от обычного здравого смысла.

.. а Рейзер не сделал для журнала соответствующего «файла» тоже из-за отсутствия здравого смысла, да? </fat>

S_ISREG считает .journal обычным файлом.

Что-то не вижу я его:

Когда он создается mkfs, его не видно. Нужно сделать mkfs.ext3, потом tune2fs -O ^has_journal, смонтировать, и на _смонтированном_ разделе tune2fs -j; наверное, то же самое происходит и при апгрейде ext2 - в давние времена я видел .journal на рабочих разделах.

Когда он создается mkfs, его не видно. Нужно сделать mkfs

Ну и много ты знаешь «обычных» файлов, для доступа к которым нужно делать mkfs с бубном?

Ну и много ты знаешь «обычных» файлов, для доступа к которым нужно делать mkfs с бубном?

Мы уже выяснили, что определению «обычного» файла у тебя свое, глубоко личное.

Нужно сделать mkfs.ext3, потом tune2fs -O ^has_journal, смонтировать, и на _смонтированном_ разделе tune2fs -j;

Ух ты, действительно появился. Только вживую его содержимое не обновляется, изменения видно только после отмонтирования-монтирования. Писать в него как-то страшно.

Писать в него как-то страшно.

А писать в файл работающей БД - не страшно? :)

Мы уже выяснили, что определению «обычного» файла у тебя свое, глубоко личное.

Ты не ответил на вопрос.

Ты не ответил на вопрос.

На вот этот?

Manhunt> Ну и много ты знаешь «обычных» файлов, для доступа к которым нужно делать mkfs с бубном?

Видишь ли, я считаю, что вопрос поставлен некорректно и прямой ответ на него невозможен.

А писать в файл работающей БД - не страшно? :)

Поменьше, чем в ФС, ибо БД в пространстве пользователя работает. Вероятность того, что оно запорет чужие буферы, практически нулевая. Ну испортит свои файлы. А вот вероятность того, что одичавший от такой подставы код журналирования шмальнёт не туда, довольно велика. Адресное пространство в ядре общее, если мне не изменяет память.

Ты бредишь.

обоснуй.

Что-то не вижу я его:

файл не обязательно имеет имя. Попробуй

# tune2fs -l /dev/sdaX | grep "Journal inode"
42:Journal inode:            8