Как в LVM2 отключить COW и вероятно снэпшоты тоже?

Скажи как включить, тогда я скажу как отключить.

Скажи как включить, тогда я скажу как отключить.

Включено по умолчанию?

вЫключено по умолчанию!

Не создавать tiny provisioning тома, не делать снапшотов. По умолчанию они и так не создаются, снапшоты автоматически тоже не делаются, так что COW не используется пока ты не задействуешь соответствующий функционал.

А если один раз задействовать снэпшоты, потом удалить созданные снэпшоты, то COW сам отключится?

Да, не знаю твой кейс и твою СУБД, но вполне можно не создавать FS в LVM томе, юзать его как raw раздел\устройство. На одну прослойку будет меньше, если конечно твоя СУБД умеет в raw.

COW работает только в процессе создания снапшота.

Это понятно про блочные устройства.

Еще интересно в каком состоянии нынче dm-integrity, чтобы оно могло считать чексуммы как ZFS ?

https://forums.servethehome.com/index.php?threads/rhel-lvm-raid-does-have-bit...

На практике не пользовался этим функционалом, так что не знаю.

А если один раз задействовать снэпшоты, потом удалить созданные снэпшоты, то COW сам отключится?

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

Бэкапы понятно штатно надо делать.

Мне вообще хотелось бы узнать, как хотя бы проконтролировать текущее состояние LVM COW (включено или выключено), кроме как листануть снэпшоты?

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

Получается, нужно обязательно выбирать только что-то одно, либо снэпшоты либо скорость работы без COW.

Я так понимаю, основная проблема, связанная с COW и отрицательно влияющая на производительность дисковой подсистемы, - это фрагментация?

Но если уж нужны снэпшоты с COW, то проще сразу взять ZFS.

Я не думаю что для этого есть какая то рукоятка или индикатор. Думаю что ситуация COW включен, но не работает аналогичен ситуации COW выключен. Если LVM не использует функционал при котором необходимо копировать при записи — он и не копирует. Ибо некуда. И незачем.

так понимаю, основная проблема, связанная с COW и отрицательно влияющая на производительность дисковой подсистемы, - это фрагментация?

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

Но если уж нужны снэпшоты с COW, то проще сразу взять ZFS.

Нужно не гадать и предполагать, а тестировать.

Хм, какой-то дефрагментатор даже есть:

https://bisqwit.iki.fi/source/lvm2defrag.html

Интересно, дефрагментация LVM возможна online?

IMHO в ZFS дефрагментация возможна только через send | receive ? Но почти online, т.е. можно добиться очень короткого downtime за счет нескольких итераций инкрементального копирования с уменьшающимся остатком.

не пользовался, не знаю

Я вообще не понимаю зачем в твоем случае (use case) нужен lvm?

mdadm – raid10, на дисках/разделах без lvm

А если один раз задействовать снэпшоты, потом удалить созданные снэпшоты, то COW сам отключится?

Да.

либо снэпшоты либо скорость работы

Снапшоты на LVM2 медленные. Больше пяти снапшотов мы вообще не делаем, потому что начинаются слишком заметные тормоза. Не для этого они.

Funny fact: в PVE вообще нет поддержки снапшотов на LVM2 — не стали делать за бесперспективностью этой идеи.

Но если уж нужны снэпшоты с COW, то проще сразу взять ZFS.

Да. Возьми сразу ZFS, серьёзно, мы так и сделали. Она рекордов скорости не ставит, но и в процессе работы не деградирует.

Снапшоты на LVM2 медленные.

На lvm thin быстрые, так как там исп. общий пул как в zfs

Там есть некоторые заморочки с объёмом, а так да. Но может, всё-таки ZFS? :-)

mdadm – raid10, на дисках/разделах без lvm

Про mdadm раньше были плохие отзывы, мол разваливается.

Да. Возьми сразу ZFS, серьёзно, мы так и сделали.

Я тоже так делал.

Она рекордов скорости не ставит, но и в процессе работы не деградирует.

Увы ZFS за счет фрагментации деградирует и еще как, через несколько лет использования под интенсивной нагрузкой СУБД с рандомным доступом и со снэпшотами ессно, скорость чтения с zvol без L2ARC падает до 1-5 Мб/c.

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

Кстати стало интересно, ZFS без снэпшотов все равно сильно фрагментируется? В нем COW работает всегда в независимости от использования снэпшотов?

Поступил ответ от эксперта по ZFS: все записи хранятся в виде отдельных COW транзакций даже в ZFS dataset без снэпшотов.

Еще интересно в каком состоянии нынче dm-integrity

В нормальных дистрибутивах - встроено в LVM и активируется ключом командной строки.

Снепшоты это оно и есть. Выход, просто не использовать снепшоты.

Ты просто себе придумал жупел и страдаешь ерундой.

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

Почему не лучшая и чем лучше?

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

Почему не лучшая и чем лучше?

Потому что в момент создания снапшота система не знает какие данные обрабатывает в памяти СУБД и база может быть неконсистентна в момент создания снапшота, если конечно не отправить команду CHEСKPOINT postgresql
https://postgrespro.ru/docs/postgresql/15/sql-checkpoint

Ну неконсистентна и что? Последняя транзакция на диске будет. При старте отмотает куда надо.

Нежелательно копировать через cp -r и подобное, т.к. там данные копируются не одновременно и может действительно получиться плохой бэкап. Хотя по факту куча людей так делает. А снапшот такой проблемы лишён.

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

Архивные логи базы данных - это конечно обязательно. Кроме того желательно делать штатные бэкапы хотя бы раз в неделю, на которые потом можно накатить архивные логи.

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

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

Нежелательно копировать через cp -r и подобное, т.к. там данные копируются не одновременно и может действительно получиться плохой бэкап. Хотя по факту куча людей так делает.

Это для баз данных вообще ни в какие ворота, ну совсем уровень детского садика для копирования базы данных с домашней подборкой музыкальных компакт дисков. За такое на нормальной работе могут и уволить, если копировать online базу без выключения СУБД образно по условному «F5». По сути это откровенное вредительство по созданию неконсистентной полукопии базы.

А снапшот такой проблемы лишён.

Откат базы на снэпшот без доката архивными логами допустим только для примитивных систем, обычно только для внутреннего использования, работающих в режиме 8 часов x 5 дней в неделю, где утеря последних нескольких даже закоммиченных транзакций не представляет никакой серьезной опасности в силу невысокой важности данных и/или возможности их ввести повторно.

Это ты только сейчас протрезвел?

Ну очевидно, что снепшот делается после остановки СУБД. Таким образом гарантируется и консистентность и минимальное время простоя

Ну очевидно, что снепшот делается после остановки СУБД. Таким образом гарантируется и консистентность и минимальное время простоя

На промышленной СУБД консистентность закоммиченных транзакций не гарантируется в случае нажатия reset на ходу? Чем это отличается от мгновенного online ZFS снэпшота ?

Нет, конечно. Ничем, кроме скорости.

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

Нет, конечно. Ничем, кроме скорости.

Можно, пожалуйста, объяснить этот ответ более подробно?

Что именно «нет», и причем тут скорость?

Уточню, мой вопрос был про промышленные РСУБД типа IBM Db2, PostgreSQL и т.п., которые обычно соответствуют всем требованиям строгого ACID по крайне мере на мастере и при синхронной репликации на репликах тоже.

Ну и аббревиатуры, cow, cat... Неужели нельзя было придумать другие, названия, говорящие о назначении утилиты?

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

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

В норме у нас есть диск или диски, в которых есть свой кеш, далее они группируются в раид контроллером со своим кешом,

Кэш контроллера отключается?

далее поверх всего этого появляется файловая система со своим буфером

Буфером чтения? Если специально не включать маргинальные режимы типа sync=disabled.

и только потом появляется СУБД со своими транзакциями, коммитами и откатами.

COMMIT в СУБД требует в т.ч. и вызова sync в FS?

lvm2defrag

Пробовал пользоваться. Нужность сомнительна. Единственное применение — для успокоения зуда от того, что логические тома не сплошные, а разбиты на несколько частей. Скрипты помогают по инструкции сгенерировать набор вызовов pvmove, которые и производят перемещения.

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

Интересно, дефрагментация LVM возможна online?

Единственные распространённые и надёжные инструменты для перемещения логических томов в LVM распространяются в составе утилит LVM и работают в онлайн-режиме. То есть дефрагментация только в режиме онлайн и возможна.

Мне, честно говоря, в принципе непонятен смысл твоих изысканий.

Ты готов отказаться от всего того, что было сделано для скорости и надежности за последние лет тридцать чтобы что? Отключить обратный кеш, то есть фактически, задрочить диск раз в десять быстрее и сообразно снизить скорость его работы ради чего? Чтобы твоя база вообще накернилась через пару лет работы вместо пары десятков лет? И все это вместо того, чтобы использовать ионисторы для сброса кеша на диск?

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

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

Мне, честно говоря, в принципе непонятен смысл твоих изысканий.

Каких именно изысканий?

Ты готов отказаться от всего того, что было сделано для скорости и надежности за последние лет тридцать чтобы что?

Надеюсь, ты про компании Sun и Oracle, а не про Western Digital или Seagate?

Отключить обратный кеш, то есть фактически, задрочить диск раз в десять быстрее и сообразно снизить скорость его работы ради чего?

Ты из каменной пещеры только что выполз? :) Про кэширование на SSD и multi-temperature storage не слыхал?

Чтобы твоя база вообще накернилась через пару лет работы вместо пары десятков лет?

Накернилась база, на промышленной СУБД, от сбоя диска? Ахаха, чо правда, такое бывает?

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

И все это вместо того, чтобы использовать ионисторы для сброса кеша на диск?

Ионисторы - это для записи данных после отключения питания?

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

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

Нука, нука, покажика описание того, как в ACID РСУБД commit, выполненный без ошибки, может потеряться.