Ext4 такая ext4

PS: В Oracle, можно обойтись без фс, а развернуть базу прямо на разделе диска. Говорят работает быстрее, опять же проблему двойного кеширования решать не надо...

AFAIK, не только в Oracle.

За счет чего журнал может оказаться поврежденным?

А вследствие случайного стечения ещё более случайных обстоятельств.

Пусть была перезапись (insert тоже сопровождается всякими перезаписями, например, индексов). Тогда у тебя в файле остались старые данные, а СУБД думает, что там новые (отложенная запись), и отрапортавала в журнал, что транзакция завершилась успешно, запись в журнал физически завершилась (другой раздел, сквозная запись...).

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

А где еще?

За счет чего журнал может оказаться поврежденным?

А вследствие случайного стечения ещё более случайных обстоятельств.

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

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

Это решение есть де-факто стандарт. Причин тому много. В частности повышенные требования к надежности журнала и пониженные требования к скорости записи в него. Кроме того это очень хорошо сказывается на производительности — в журнал запись линейная и соотв. она быстро пробивает любой кеш, делая кеширование очень дорогим и глупым в плане расходования памяти (линейная запись!), соотв. вынос меньше нагружает диск — головки почти не дергаются, можно поставить максимальный размер упреждающего чтения и т.п. А вот на диске с данными часто происходит случайное чтение, которое хорошо кешируется и часто дергает головки (был бы тут журнал, головки пришлось бы дергать в два раза чаще)... Короче, оптимизация дисковой системы по скорости и по надежности для журнала и для данных совершенно разная. И совмещение этих двух типов данных на одном диске резко снижает такое узкое место все бд, как скорость работы с диском.

Журнал решает проблему блэкаута - и только.

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

совмещение этих двух типов данных на одном диске резко снижает такое узкое место все бд, как скорость работы с диском

Экстремальная производительность нужна отнюдь не всем.

Это решение есть де-факто стандарт.

А можешь ссылочек накидать про такую настройку СУБД?

IBM DB2 9.7.

казалось бы причем тут ФС?

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

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

Экстремальная производительность нужна отнюдь не всем.

Это не экстремальная производительность. Это правила хорошего тона, примерно, как не хранить числа в текстовы полях.

У можешь ссылочек накидать про такую настройку СУБД?

Достатчно книги Gregory Smith «PostgreSQL 9.0 High Performance». Там достатончо полно описывается настройка этой СУБД, а поскольку рассказано почему так устроено и какие из этого можно делать выводы, то применима к любой СУБД.

IBM DB2 9.7.

Кстати, да. Забыл про нее.

А почему ты исключаешь неисключаемые факторы?

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

в этом случае накатывают последние n-транзакций из лога, разве нет? Называется log redo.

В Oracle, можно обойтись без фс

и в squid :). И ещё много где.

в этом случае накатывают последние n-транзакций из лога, разве нет? Называется log redo.

ну да, только нет никаких данных про необходимое значение этого n.

В Oracle, можно обойтись без фс

и в squid :). И ещё много где.

Речь шла про базы данных.

А почему ты исключаешь неисключаемые факторы?

Если это часто проявляющийся баг, то его нужно поймать и починить.

Если это популярная аппаратная проблема, то специально для нее нужно предусмотреть какой-то воркэраунд в алгоритмах.

А оправдывать собственное кривое поведение тем, что всё равно нас всех съедят неведомые трудности — неспортивно. Если уж всерьёз думать о всевозможных сбоях неизвестного происхождения, то это к таненбуаму надо с его микроядром..

никто. вообще никогда не имел проблем с файловой системой. почитаю на досуге мануалы.

только нет никаких данных про необходимое значение этого n.

А сколько есть в логе столько и накатывается, например.

В общем, в любом случае любая СУБД расчитывает что до какого-то момента времени ничего не терялось. Имхо, это то к чему должны стремиться файлухи. Впрочем, ответ вроде как уже звучал, data=journal.

Это не экстремальная производительность.
Gregory Smith «PostgreSQL 9.0 High Performance»

Таки это High Performance. То есть актуально для серверов, где и в самом деле должно быть резервное питание.

сделал. насчёт второго почитаю.

А сколько есть в логе столько и накатывается, например.

Правильно, по максимуму, но только не факт, что этого хватит.

В общем, в любом случае любая СУБД расчитывает что до какого-то момента времени ничего не терялось. Имхо, это то к чему должны стремиться файлухи.

Да.

Впрочем, ответ вроде как уже звучал, data=journal.

Ну вообще-то этого мало. Все-таки это только защита от потери данных вследствии ошибок фс, но никак не защита от потери данных вследствии БП.

/etc/fstab *теперь* выглядит так -

 /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# / was on /dev/sda5 during installation
UUID=2df64c86-d83f-4dba-800d-699a1b3bb259 /               ext4    data=journal,errors=remount-ro 0       1
# /home was on /dev/sda2 during installation
UUID=8cfaad2a-6b68-46b6-99ac-6def5ea87e26 /home           ext4    defaults,data=journal        0       2
# swap was on /dev/sda7 during installation
UUID=c0080c5e-7580-4362-a38c-75b20a107555 none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0

это надо обладать ненастроенным авесомом, ноутбуком с убитой практически батареей и интересной задачей; заряд виден, если только htop запустить:-) ем кактус, да.

Debian Wheezy,

uarthur@localhost:~$ uname -a
Linux localhost 3.2.0-2-686-pae #1 SMP Mon Jun 11 18:27:04 UTC 2012 i686 GNU/Linux

Таки это High Performance. То есть актуально для серверов, где и в самом деле должно быть резервное питание.

В книгах по High Performance пишут сразу и только про High Performance? В книгах «%theme% для профессионалов» пишут только для профессионалов (и для профессионалов ли вообще)?

Линейный лог убивает кеш. Все, на диске где лог, кеширования фактически нет. Это не high performance. Это тупо логика, как не стрелять себе в ногу, не ссать в штаны на морозе, не ездить в Бабищево и т.д.

добавил data=journal.

мало поможет. Лучше сделай еще

# echo 0 > /proc/sys/vm/dirty_background_ratio

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

Линейный лог убивает кеш. Все, на диске где лог, кеширования фактически нет.

Может быть, это зависит от размеров лога и от доступного объема оперативы?

Да ничего интересного что то, в syslog по крайней мере. Не пойму какой временной интервал кидать. На лоре дата показывается московская?

Может быть, это зависит от размеров лога и от доступного объема оперативы?

Обычно линейный лог быстро превышает пределы доступной оперативной памяти, ее не так много, особенно на домашних компах. Кроме того тратить впустую (а под линейный лог это пустая трата) глупо.

Впрочем посмотри размер своего лога и если такая потеря памяти тебя устроит — as you like. + не забывай про диск, кеш это половина проблемы.

Если это часто проявляющийся баг, то его нужно поймать и починить.

И вот тут ты должен много раз выключить питание, поймать баг и починить его!

И вот тут ты должен много раз выключить питание, поймать баг и починить его!

Внутри qemu - почему бы и нет?

Обычно линейный лог быстро превышает пределы доступной оперативной памяти

Хм. А вот тут http://www.postgresql.org/docs/9.1/static/wal-configuration.html пишут иначе:

There will always be at least one WAL segment file, and will normally not be more than (2 + checkpoint_completion_target) * checkpoint_segments + 1 or checkpoint_segments + wal_keep_segments + 1 files. Each segment file is normally 16 MB (though this size can be altered when building the server). You can use this to estimate space requirements for WAL. Ordinarily, when old log segment files are no longer needed, they are recycled (renamed to become the next segments in the numbered sequence). If, due to a short-term peak of log output rate, there are more than 3 * checkpoint_segments + 1 segment files, the unneeded segment files will be deleted instead of recycled until the system gets back under this limit.

То есть ожидаемый суммарный размер файлов - 160 Mb. Не смертельно для машины с 2+ Гб оперативы.

опять же проблему двойного кеширования решать не надо...

O_DIRECT же

То есть ожидаемый суммарный размер файлов - 160 Mb. Не смертельно для машины с 2+ Гб оперативы.

Вообще-то это значение очень неприятно. От 2Гб по дефолту только 20 (vm.dirty_ratio) под кеш фс уодит (и это значение не случайно) это 400Mb, больше трети из этого ты хочешь просто выкинуть? + Опять же под лог стараются выдать побольше (глубина отката, скорость работы,...). На ноуте у меня для сегментов выставлено значение в 32. На серваке в 64.

Странно. Вообще-то рекомендованный способ решения - опция nodelalloc, но в 3.2 должны быть патчи, которые уменьшают вероятность самой проблемы.

только нет никаких данных про необходимое значение этого n.

(ковырял недавно устройство журнала в reiserfs)
У журнала есть кольцевой буфер и заголовок журнала, отдельным блоком. Все транзакции пронумерованы. Когда нужно что-то писать на диск, формируется транзакция (заголовок, блоки на запись и завершающий блок), в ней прописываются: номер текущей транзакции и блоки, которые надо записать. После того, как данные упали в кольцевой буфер журнала (sync), обновляется номер последней завершённой транзакции в заголовке журнала и её позиция в кольце. После этого данные пишутся на диск в назначенные места.

При монтировании раздела журнал сканируется вперёд, и, если встречаются данные, похожие на транзакцию с порядковым номером больше, чем номер в заголовке журнала, данные транзакции пишутся на диск. И так пока транзакции не кончатся. Так вычисляется это самое n.

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

При отложенной записи СУБД считает что был sync диска (данные физически записались), в то время как на самом деле его не было.

Я писал о том, как делается journal replay, а именно о том, как определяется, сколько записей надо проигрывать.

При отложенной записи СУБД считает что был sync диска (данные физически записались), в то время как на самом деле его не было.

Я теперь знаю, как делается журналирование (раньше как-то не задумывался над этим), и как writeback в контроллере диска может обломать это самое журналирование.

Регулярно вырубается системник при скачках в сети, в среднем больше одного раза в неделю. При критических перегревах тоже вырубается. Раньше иногда при загрузке не врубалась видуха, приходилось самому ресетить. Система на ext4, основной пользователь на ext3, дополнительные файлопомойки на ntfs и fat32. Такого страха как у тебя не припомню. Иногда мог повредиться какой файлик или кэш устраивал машину времени: вроде бы файлы от старой компиляции давно удалены а они линкуются. Похоже и у тебя чудят кэши - слишком редко синхронизируют своё содержимое с носителями информации, как при использовании дискеты. Попробуй отключить всякие тормозящие винт непомуки, tracker-extract и проверить содержимое /etc/fstab

nepomukи кстати могут быть,т.к. кде тоже поставлено, tracker-extract нет, /etc/fstab да, посмотрю)

На лоре дата показывается московская?

Да.

От 2Гб по дефолту только 20 (vm.dirty_ratio) под кеш фс уодит

под кэш фс (page cache) уходят все доступные страницы памяти. А dirty_*_ratio регулирует поведение грязных страниц.

Кроме того, есть background_ratio. Я бы рекомендовал маленький vm.dirty_background_ratio и высокий vm.dirty_ratio (для борьбы с внезапными нагрузками, расчёт на то что в среднем диск пишет быстрее чем прибывают новые данные и до vm.dirty_ratio не дойдёт). С маленьким dirty_ratio это будет напоминать mount -o sync (имхо).

под кэш фс (page cache) уходят все доступные страницы памяти. А dirty_*_ratio регулирует поведение грязных страниц.

Интерес для сохранения данных при БП представляют только грязные страницы. И vm.dirty_ratio это показатель который система не превысит, т.е. больше чем (vm.dirty_ratio)% грязных данных не будет. vm.dirty_background_ratio — это показатель с начиная с которого начинается фоновая запись грязных страниц.

Я бы рекомендовал маленький vm.dirty_background_ratio и высокий vm.dirty_ratio

Обнулять vm.dirty_background_ratio тоже не рекомендуется и вообще, делать его надо сравнимым с размерами блоков в фс, т.е. в некоторых случая и под 1 gb будет хорошо. Высокий vm.dirty_ratio точно делать не нужно — ибо это отнимет ценные мегабайты оперативки у чистого кеша (чтение данных) и у софта. Можно вспомнить нормальное распределение и взять этот показатель равным трем объемам записей за единицу времени при средней скорости, и надеяться, что цпт тут применимо.

С маленьким dirty_ratio это будет напоминать mount -o sync (имхо).

абсолютно верно

ибо это отнимет ценные мегабайты оперативки у чистого кеша

а кто сказал что эти страницы не будут читать? Да и не поможет это сохранить кэш, туда в любом случае попадает последнее записанное/считанное. Алгоритмы типа LRU для page cache не захотели внедрять, хотя попытки были.

а кто сказал что эти страницы не будут читать? Да и не поможет это сохранить кэш, туда в любом случае попадает последнее записанное/считанное. Алгоритмы типа LRU для page cache не захотели внедрять, хотя попытки были.

Если это запись линейного лога, то читать их будут ой как редко.

Если это запись линейного лога, то читать их будут ой как редко.

Что ещё за линейный лог? :) Мы же про БД говорили. Там журнал+данные.

А для лога можно и O_DIRECT, только вот софт что-то не торопится это использовать.