Ext4 такая ext4

ох, лол, давай вспомним тогда времена, когда ext4 была ext4dev?!

По существу возражения есть?

А где это существо?

Ожидать-то можно всего чего угодно, но ведь ожидания могут и не оправдаться?

1. Как минимум, должны без искажений сохраниться файлы, в которые «достаточно давно» (например, с момента последнего отмонтирования) не было записи.

В реальности это не так. man vm.dirty_background_ratio. Данные могут храниться в кеше годами без синронизации с диском. И для временных файлов (например при компиляции ядра) это хорошо, ибо и все равно потом удалят.

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

В реальности файлы могут потярятся на диске. fsck и потом найдет и присоединит к нужной директории, но факт есть факт.

3. Если делался rename, то результирующий файл либо должен сохраниться старым (как если бы никакого rename даже начаться не успело), либо должен сохраниться новым без искажений — даже если в этот новый файл непосредственно перед rename производилась запись.

Если rename не сопровождался перезаписью файла иначе может быть все что угодно. В случае массовых remane (например 1.000.000 файлов в одной директории) последствия блэкаута могут быть печальные.

4. Какие-то еще гарантии нужны для того, чтобы на ФС можно было разместить данные ACID СУБД. Тут я не в курсе, что конкретно требуется.

Конктретно требуется четкое выполнение транзакций соотв. уровня.

QNX6FS смотрит на неё, как на корявую пионерскую поделку.

Пруф?

С тех пор, когда нтфс стала самой устойчивой фс к внезапным блэкаутам.

Не смеши людей.

По существу возражения есть?

По поводу того, что «ФС легко приводится в консистентное состояние командой mkfs»? Это случай так называемого вранья. Команда mkfs создает новую ФС // К.О.

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

В реальности файлы могут потярятся на диске

Это было не отверждение, это то какой людям бы хотелось видеть файлухи. Это к вопросу о критериях сравнения надёжности фс.

Это было не отверждение, это то какой людям бы хотелось видеть файлухи. Это к вопросу о критериях сравнения надёжности фс.

Надежность сохранности данных кажется градуируется уровнем транзакции. К чему был тот коммент я вообще не понял.

Ожидать-то можно всего чего угодно, но ведь ожидания могут и не оправдаться?

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

В реальности это не так. man vm.dirty_background_ratio. Данные могут храниться в кеше годами без синронизации с диском. И для временных файлов (например при компиляции ядра) это хорошо, ибо и все равно потом удалят.

Ты читал текст на который отвечаешь? Прочитай еще разок: «с момента последнего отмонтирования». В твоей вселенной при отмонтировании синхронизация с диском не производится?

В реальности файлы могут потярятся на диске. fsck и потом найдет и присоединит к нужной директории, но факт есть факт.

fsck в случае ext4 не слишком-то способствует нахождению данных. Вот такой факт, увы.

Если rename не сопровождался перезаписью файла иначе может быть все что угодно.

Не распарсил.

Конктретно требуется четкое выполнение транзакций соотв. уровня.

Транзакция - это сущность, которую СУБД должна реализовать в терминах ФС с помощью системных вызовов. Вопрос в том, что должна гарантировать ФС, чтобы было возможно разместить поверх неё ACID СУБД.

На то оно и dev, а reiserfs во времена 2.4 не была обозначена как dev, а считалась стабильной.

То есть по делу тебе сказать нечего. Ок.

Кстати, а какой дистр/версия ядра? Вроде это поведение давно исправили.

Надежность сохранности данных кажется градуируется уровнем транзакции.

угу. И так же хотелось бы чтобы другие транзакции (даже незавершённые или отменённые) не повреждали нерелевантные к ним данные.

И для временных файлов (например при компиляции ядра) это хорошо, ибо и все равно потом удалят.

Для временных файлов хорошо tmpfs, без журналов и прочей избыточной требухи.

Ожидать-то можно всего чего угодно, но ведь ожидания могут и не оправдаться?

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

Или ожидания были никак не связаны с реальностью. А взяты с потолка (высосаны из пальца).

В реальности это не так. man vm.dirty_background_ratio. Данные могут храниться в кеше годами без синронизации с диском. И для временных файлов (например при компиляции ядра) это хорошо, ибо и все равно потом удалят.

Ты читал текст на который отвечаешь? Прочитай еще разок: «с момента последнего отмонтирования». В твоей вселенной при отмонтировании синхронизация с диском не производится?

«с момента последнего отмонтирования» было написано во-вторых в скобках, а в-третьих со словом «например»

В реальности файлы могут потярятся на диске. fsck и потом найдет и присоединит к нужной директории, но факт есть факт.

fsck в случае ext4 не слишком-то способствует решению проблем. Вот такой факт.

Он решает конкретные задачи, в т.ч. и для ext4. Главная задача fsck — восстановить целостность фс. Восстановления потерянны данных это _не_ задача fsck.

Конктретно требуется четкое выполнение транзакций соотв. уровня.

Транзакция, это сущность, которую СУБД должна реализовать в терминах ФС с помощью системных вызовов. Вопрос в том, что должна гарантировать ФС, чтобы было возможно реализовать поверх неё ACID СУБД.

Транзакция это общее понятие для описания надежности работы с данными, оно применимо не только в СУБД, но и в фс, и даже к прошивке жесткого диска (или raid'a).

1. согласен;
2. не согласен, так как это сильно зависит от консистентности структуры дерева;
3. это имеет отношение к COW на уровне метаданных — а теперь вспомни, где это реализовано;
4. ну консистентность, атомарность, долговечность и изоляция: изоляцию ты уже привёл, атомарная ФС известна мне одна — это 4-й Рейзер, консистентность спорна, если не указан её уровень, а долговечность зависит от архитектуры ФС (бтрфс, например, сюда не подходит).

рейзер3.6, ЕМНИП, рекомендовалась к использованию после 2.6.13.

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

На 2.4.х kernel panic вылетал с высокой вероятностью просто от вызова rmmod something. Наверное бинарник rmmod забыли пометить как dev, да.

Во-первых, не rmmod, а rmmod -f. Во-вторых, пользователь не мог сделать rmmod.

«с момента последнего отмонтирования» было написано во-вторых в скобках, а в-третьих со словом «например»

Разумеется, потому что понятие «достаточно давно» можно определить как-нибудь иначе. Например, «с момента последнего вызова sync». Или еще как-то, поэтому я решил не вдаваться в детали.

Он решает конкретные задачи, в т.ч. и для ext4. Главная задача fsck — восстановить целостность фс. Восстановления потерянны данных это _не_ задача fsck.

Какой смысл в целостности ФС, если она невменяемым и непредсказуемым образом теряет данные, и заявляет, что это не её проблемы? Давайте тогда сразу после блэкаута делать mkfs, так по-крайней мере будет уверенность, что все данные в самом деле восстановлены, пусть и из бэкапа.

Транзакция это общее понятие для описания надежности работы с данными, оно применимо не только в СУБД, но и в фс, и даже к прошивке жесткого диска (или raid'a).

Бгг. Давай-ка скатимся в конкретику. У меня есть SQL-таблица из двух столбцов, оба с индексами. Я делаю в неё insert, и тут происходит блэкаут. Какие вызовы и в какой последовательности должна делать СУБД, чтобы ФС её не подвела?

не согласен, так как это сильно зависит от консистентности структуры дерева;

Проблему консистентности структур ФС, в том числе деревьев, должен решать журнал. Не?

это имеет отношение к COW на уровне метаданных — а теперь вспомни, где это реализовано

Не улавливаю связи с COW..

Проблему консистентности структур ФС, в том числе деревьев, должен решать журнал. Не?

Ну так структура и восстановится целостная. Вот только она не обязательно будет соответствовать той, которая была до сбоя.

Не улавливаю связи с COW.

А как, по-твоему, должна сохраняться предыдущая информация при обеспечении атомарности?

«с момента последнего отмонтирования» было написано во-вторых в скобках, а в-третьих со словом «например»

Разумеется, потому что понятие «достаточно давно» можно определить как-нибудь иначе. Например, «с момента последнего вызова sync». Или еще как-то, поэтому я решил не вдаваться в детали.

«давно» это временная характеристика, какое отношение к ней имеет sync, umount ?

Он решает конкретные задачи, в т.ч. и для ext4. Главная задача fsck — восстановить целостность фс. Восстановления потерянны данных это _не_ задача fsck.

Какой смысл в целостности ФС, если она невменяемым и непредсказуемым образом теряет данные, и заявляет, что это не её проблемы? Давайте тогда сразу после блэкаута делать mkfs, так по-крайней мере будет уверенность, что все данные в самом деле восстановлены, пусть и из бэкапа.

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

Транзакция это общее понятие для описания надежности работы с данными, оно применимо не только в СУБД, но и в фс, и даже к прошивке жесткого диска (или raid'a).

Бгг. Давай-ка скатимся в конкретику. У меня есть SQL-таблица из двух столбцов, оба с индексами. Я делаю в неё insert, и тут происходит блэкаут. Какие вызовы и в какой последовательности должна делать СУБД, чтобы ФС её не подвела?

После блекаута уже вызовы не сделаешь. Если у тебя нет бесперебойника и при блекауте все обесточивается, то тебе нужна сквозная запись у бд, фс, диска и все равно целостность данных будет только до последней успешной завершенной транзакции. т.е. твой инсерт на*й откатиться если транзакция не завершилась.

Ну так структура и восстановится целостная. Вот только она не обязательно будет соответствовать той, которая была до сбоя.

Журнал должен содержать информацию достаточную для того, чтобы rollback вернул дерево к тому виду, в котором оно было до начала транзакции. Казалось бы, это самый простой способ вернуть целостную структуру.

А как, по-твоему, должна сохраняться предыдущая информация при обеспечении атомарности?

1. Рассматриваем последовательность системных вызовов write - rename над один и тем же файлом. ФС должна разделить эти вызовы барьером (http://en.wikipedia.org/wiki/Memory_barrier): пока все данные от write полностью не вывалены на диск, отправлять на диск метаданные от rename - запрещено.

2. Rename сам по себе должен быть атомарен по отношению к блэкатуту. Это делается силами журнала.

/dev/sda1 on / type jfs (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
/dev/md0 on /home type nilfs2 (rw,noatime,gcpid=7862)

Проблемы ext4 шерифа как известно...

«давно» это временная характеристика, какое отношение к ней имеет sync, umount ?

Угадай, почему слова «достаточно давно» написаны в кавычках?

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

Я не против отката моей sql-транзакции. Тут другая проблема: как сделать так, чтобы от файлов БД после блэкаута не осталась такая каша, в которой СУБД уже никогда не сможет разобраться. Скажем, ext4 возьмет, да и обнулит все файлы :) Это уже не откат sql-транзакции, а уничтожение базы получается. А теперь повторю вопрос: «Какие вызовы и в какой последовательности должна делать СУБД, чтобы ФС её не подвела?»

ну консистентность, атомарность, долговечность и изоляция: изоляцию ты уже привёл, атомарная ФС известна мне одна — это 4-й Рейзер, консистентность спорна, если не указан её уровень, а долговечность зависит от архитектуры ФС (бтрфс, например, сюда не подходит).

Я совсем другое имел ввиду. ACID требуется не от ФС (это слишком накладно в плане быстродейтсвия), а от СУБД.

Проблемы ext4 шерифа как известно...

про nilfs2 тут тоже писали, так что я не рискнул её ставить.

Журнал должен содержать информацию достаточную для того, чтобы rollback вернул дерево к тому виду, в котором оно было до начала транзакции. Казалось бы, это самый простой способ вернуть целостную структуру.

А кто гарантирует целостность журнала? Чем больше его величина, тем вероятнее, что в нём будут ошибки.

Rename сам по себе должен быть атомарен по отношению к блэкатуту. Это делается силами журнала.

Если питание вырубится посредине операции, от этого ничто не защитит. А если данные перед этим и сохранены, то получается COW. А теперь возвратимся к моему вопросу — много таких ФС?

Так вот для этого БД пускают на диск в обход ФС прямой записью.

Я не против отката моей sql-транзакции. Тут другая проблема: как сделать так, чтобы от файлов БД после блэкаута не осталась такая каша, в которой СУБД уже никогда не сможет разобраться. Скажем, ext4 возьмет, да и обнулит все файлы :) Это уже не откат sql-транзакции, а уничтожение базы получается. А теперь повторю вопрос: «Какие вызовы и в какой последовательности должна делать СУБД, чтобы ФС её не подвела?»

Старческий маразм? Вызовы СУБД при выполнении транзакции от фс не зависят, они ДЕТАЛЬНО ПРОПИСАНЫ в описании соотв. уровня транзакции и отклонение от этого НЕДОПУСТИМО. Еще раз повторю: если у тебя нет бесперебойника то ТОЛЬКО СКВОЗНАЯ ЗАПИСЬ (write throw) в бд, фс, дисковой системе спасет твои данные. Отложенная запись это софтовый обман СУБД для повышения скорости работы — СУБД в этом случае сообщается, что данные ФИЗИЧЕСКИ записаны на диск, хотя они только в кеше (фс || диска), и если отрубят свет то данные в кеше просто изчезнут, и восстановеление целостности фс, может нарушить целостность бд.

Да мне пофиг - у меня на работе в хомяке ничего важного не лежит. К тому же он на RAID0, так что главная опасность исходит не от FS.

Угадай, почему слова «достаточно давно» написаны в кавычках?

Да фиг его знает, но судя по тому, что ты про это пишешь, это может быть что угодно от 5-ти минут до метафоры всеобщего саморазрушения.

А кто гарантирует целостность журнала?

Её легко обеспечить за счет того, что у журнала очень простая (линейная) структура.

The internal format of the journal must guard against crashes while the journal itself is being written to. Many journal implementations (such as the JBD2 layer in ext4) bracket every change logged with a checksum, on the understanding that a crash would leave a partially written change with a missing (or mismatched) checksum that can simply be ignored when replaying the journal at next remount.

Чем больше его величина, тем вероятнее, что в нём будут ошибки.

С чего бы?

Если питание вырубится посредине операции, от этого ничто не защитит.

Журнал специально предназначен для того, чтобы разобраться с теми операциями, которые были прерваны отключением питания.

Старческий маразм?

Да, похоже, что тебя накрыло.

Отложенная запись это софтовый обман СУБД для повышения скорости работы — СУБД в этом случае сообщается, что данные ФИЗИЧЕСКИ записаны на диск, хотя они только в кеше (фс || диска), и если отрубят свет то данные в кеше просто изчезнут, и восстановеление целостности фс, может нарушить целостность бд.

СУБД ничего не мешает жить с отложенной записью, если предоставить ей подходящие гарантии.

восстановеление целостности фс может нарушить целостность бд

Такое поведение ФС должно быть недопустимо, только и всего.

Журнал специально предназначен для того, чтобы разобраться с теми операциями, которые были прерваны отключением питания.

Не только. И под словом «разобраться» подразумевается «восстановить целостность фс», т.е. чуть менее, чем всегда это откатить последнюю незавершенную транзакцию фс.

СУБД ничего не мешает жить с отложенной записью, если предоставить ей подходящие гарантии.

Только если есть бесперебойник, который позволяет завершить все отложенные записи в случае приближения такого БП, как внезапное обесточивание дисков.

восстановеление целостности фс может нарушить целостность бд

Такое поведение ФС должно быть недопустимо, только и всего.

Это фраза из разряда «недопустимо быть бедным». Впрочем, я неверно выразился. ФС восстанавливает свою целостность, и только после этого свою целостность сможет (или не сможет) восстановить СУБД. Следствием этого может оказаться, что придется откатываться существенно дальше, чем последняя успешно завершившаяся транзакция СУБД.

«давно» это временная характеристика, какое отношение к ней имеет sync, umount ?

Это события во времени. У данных которые были записаны до последнего sync больше шансов выжить.

СУБД ничего не мешает жить с отложенной записью, если предоставить ей подходящие гарантии.

Только если есть бесперебойник, который позволяет завершить все отложенные записи в случае приближения такого БП, как внезапное обесточивание дисков.

Почему ты так думаешь? Мне вот кажется, что хватит барьеров + обязательства со стороны ФС не слишком сильно портить файл, даже если в него недавно записывали. http://www.sqlite.org/fileformat2.html

Следствием этого может оказаться, что придется откатываться существенно дальше, чем последняя успешно завершившаяся транзакция СУБД.

Одно дело - откатить несколько последних транзакций, и другое - получить полностью разрушенную БД. Так вот чтобы избегать второго и всегда ограничиваться первым, придётся отказаться от позиции «стуктура ФС сохранна, а ваши 5 секунд назад модифицированные файлы мы обнулили».

Её легко обеспечить за счет того, что у журнала очень простая (линейная) структура.

Ну так запомни, что 100% гарантии тебе никто не даст. И если целостность самой структуры журнала ещё можно восстановить, то метаданные журналирования — не обязательно.

С чего бы?

man теория_надёжности

Журнал специально предназначен для того, чтобы разобраться с теми операциями, которые были прерваны отключением питания.

Ты так говоришь, будто бы журнал — это отдельная сущность по типу Святого Духа. А он хранится на диске так же, как и остальная ФС, и подвержен влиянию внезапности наравне с остальными данными.

обязательства со стороны ФС не слишком сильно портить файл

sudo tune2fs --пожалуйста-не-слишком-сильно-искажай-файлы /dev/sda1

Или как это понимать?

Ты так говоришь, будто бы журнал — это отдельная сущность по типу Святого Духа. А он хранится на диске так же, как и остальная ФС, и подвержен влиянию внезапности наравне с остальными данными.

ФС - это сложная структура данных, расположенная частично на диске и частично - в оперативной памяти. Журнал - часть ФС, которая обеспечивает восстановление после блэкаута. Другие части ФС решают другие задачи. Причем тут Святой Дух и внезапности?

sudo tune2fs --пожалуйста-не-слишком-сильно-искажай-файлы /dev/sda1
Или как это понимать?

Перечитай пункт 4: Ext4 такая ext4 (комментарий) Это не ко мне, а к экспертам в области построения СУБД.

Почему ты так думаешь? Мне вот кажется, что хватит барьеров + обязательства со стороны ФС не слишком сильно портить файл, если при записи не меняется его размер.

Не хватит. Пусть была перезапись (insert тоже сопровождается всякими перезаписями, например, индексов). Тогда у тебя в файле остались старые данные, а СУБД думает, что там новые (отложенная запись), и отрапортавала в журнал, что транзакция завершилась успешно, запись в журнал физически завершилась (другой раздел, сквозная запись...). БП, данные утеряны, но согласно журналу целостность СУБД вроде как есть, хотя на самом деле ее нет. Что делать? Как восстановить целостность СУБД? Если транзакция была сложной и меняла еще какие-то данные, то может быть уже никак. Ибо по-сути это не БП в середине транзакции, а БП при хранении данных. От этого журнал транзакций не защищает, защищать от этого — задача фс и дисковой системы. Все, данные утеряны, восстановить их возможности нет, чтобы фс не делала. Беда в том, что из-за этого может нарушится целостность данных на уровне фс, и тогда потери будут больше. Фс от этого защищает, свою целостность она восстановит с минимальными (в иделе) потерями данных. Но целостность данных на уровне фс != целостности данных в СУБД, где есть еще куча связанных штук, самые очевидные из которых это индексы. Да, часть данных будет потеряна при хранении, соотв, все связи, которые были связанны с утерянными данными придется пересчитывать. В зависимости от ситуации это может вылится в потерю последнего инсерта + пересчет индексов или во что-то большее. Все зависит от того, с чем были связанны последние данные. И да, в этом случае непонятно, как узнать а какие транзакции были на самом деле завершены (вплоть до физической записи на диск).

Поэтому бесперебойник при отложенной записи в фс или дисковой системе де-факто необходим.

Одно дело - откатить несколько последних транзакций, и другое - получить полностью разрушенную БД. Так вот чтобы избегать второго и всегда ограничиваться первым, придётся отказаться от позиции «стуктура ФС сохранна, а ваши 5 секунд назад модифицированные файлы мы обнулили».

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

При том, что если повреждённым окажется и журнал, и данные, то ты для сохранности последних ничего не сможешь сделать.

Дык ФС там и ни при чём. Её не должно быть как промежуточного звена вообще в этом случае.

Или как это понимать?

Вот тут http://www.sqlite.org/c3ref/io_methods.html принята следующая классификация гарантий ФС:

The SQLITE_IOCAP_ATOMIC property means that all writes of any size are atomic. The SQLITE_IOCAP_ATOMICnnn values mean that writes of blocks that are nnn bytes in size and are aligned to an address which is an integer multiple of nnn are atomic. The SQLITE_IOCAP_SAFE_APPEND value means that when data is appended to a file, the data is appended first then the size of the file is extended, never the other way around. The SQLITE_IOCAP_SEQUENTIAL property means that information is written to disk in the same order as calls to xWrite().

Очевидно, что линуксячих гарантий м не хватает, т.к. в «безопасном» режиме они заваливают диск грудой никому не нужных вызовов sync. Чего конкретно не хватает - лучше узнать у них напрямую.

При том, что если повреждённым окажется и журнал

За счет чего журнал может оказаться поврежденным? Недозаписанным - да, может, но для него это штатная ситуация.

Очевидно, что линуксячих гарантий м не хватает, т.к. в «безопасном» режиме они заваливают диск грудой никому не нужных вызовов sync. Чего конкретно не хватает - лучше узнать у них напрямую.

Именно sync им и не хватает, т.е. транзакция->sync->запись в журнал об успешном завершении транзакции->sync. Sync можно назвать режимом сквозной записи для фс.

Дык ФС там и ни при чём. Её не должно быть как промежуточного звена вообще в этом случае.

Она есть дефакто. Кеды за собой тащат то ли постгрес, то ли мускуль, фирефокс хранит свои настройки в скулайте, и так далее — продолжать можно до бесконечности. Отдельного раздела им никто не выделит, разумеется — так что данные лягут на ФС.

Именно sync им и не хватает, т.е. транзакция->sync->запись в журнал об успешном завершении транзакции->sync.

В данном случае адекватнее был бы барьер, а не sync. Но линакс не умеет барьеры — увы.

Sync можно назвать режимом сквозной записи для фс.

Правильнее назвать его костылём, в данном конкретном случае.