Ох BTRFS, ну сколько можно

тестировал дефрагментатор на снапшотах

и что могло бы пойти не так…

SSD

фрагментация

CoW-файлухи фрагментируются по определению, с SSD на фрагментацию можно наплевать

RAW диск виртуалки на разделе BTRFS

для баз данных нужно отключать CoW опцией nodatacow, правда, тогда и снапшоты отключатся

BTRFS, как на единстрвенной COW которая не ест SSD

lol. Lmao even!

https://ar5iv.labs.arxiv.org/html/1707.08514

BTRFS, как на единстрвенной COW которая не ест SSD

Что имеется в виду под словами «не ест»?

тогда и снапшоты отключатся

Нет, не отключаются.

Мне COW нужна исключительно для репликации, отключать COW нельзя :) Дефрагментатор основан на стандартном btrfs fi defragment, так что если я что-то и сломал, то с его помощью.

https://ar5iv.labs.arxiv.org/html/1707.08514

они хотят сказать, что btrfs на каждый МБ данных записывает по факту 32 МБ? похоже на полную чепуху

как снапшоты могут создаваться без CoW?

https://habr.com/ru/articles/476414/
+ я могу потдвердить - я проводил тесты и результаты были похожие.

Это видимо устаревшие или неверные данные, у меня другая информация, а даже софт написал с помощью которого измерил write amplification для всех описанных способов. А также для LVM, ext4, xfs, в общем про это я знаю всё :)

На каждый мегабайт в их тестах. Смотри методики, там довольно странные штуки типа записи 10 мегабайт блоками по 4к за раз с fsync после каждого блока.

Они выложили данные и методики, ты не выложил. Кому мы верим?

Там CoW отключается только для обычной записи. После снапшота CoW случается однократно. Подробности уже сами ищите.

Что-то не вижу даты выпуска статьи.

погуглил, с nodatacow можно делать снапшоты, но при этом cow включится принудительно)

https://unix.stackexchange.com/questions/285763/taking-snapshots-of-a-btrfs-volume-mounted-with-nodatacow

Да, я тестировал также для всех recordsize (ZFS) начиная c 4к и выше и для всех блоков fio начиная с 4к и выше. Так как у меня 70% это 4к блоки random write у виртуалки (а чтобы это измерить мною был написан ещё один софт лол), я всё тестировал в этом контексте.

что-то такое я и подозревал, наркоманы какие-то

2017

https://arxiv.org/abs/1707.08514

Опять в заблуждение вводишь, аноним. Вот по твоей же ссылке:

On a NOCOW file the first write to a fileblock (4096 bytes) after a snapshot must still be COW, because the snapshot locks the old version in place, and now the fileblock has changed, so it MUST be written elsewhere despite the NOCOW in ordered to keep the snapshot as it was. However, the file does retain the NOCOW attribute and additional writes to the same fileblock will be in-place… until the next snapshot of course.

Да нет, это ОЧЕНЬ частый сценарий у всякого говнософта на электроне и у firefox. Fsync опционален.

Вот тебе пример такого поведения, которое реально убило диски: https://bgr.com/tech/spotify-has-been-quietly-killing-your-ssds-life-for-months/

я имел в виду: включится при создании снапшота

я ж недоумевал, как можно создать снапшот без cow, а ларчик просто открывается: для снапшота корова включается принудительно

Никому верить нельзя, даже себе. Мне можно.

ок, значит хорошо что я btrfs только для корня выбрал, на хомяке у меня ext4)

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

Да, с фрагментацией на SSD жить можно, тесты показали, что скорость линейного чтения на фрагментированной BTRFS падает всего в 2 раза, терпимо. Но у меня другой случай - я её хотел реплицировать на другой хост, а там HDD. Так вот при HA на этот хост с HDD, сайт просто не поднимется, так как не сможет достаточно быстро прочитат фрагментированные таблицы mysql. С фрагментированной BTRFS на HDD неюзабелен, это черепаха, поэтому и работал над дефрагментатором.

Снапшоты и дефрагментацию делаешь ? Как часто?

Немного оффтопика: может быть, имеет смысл репликацию делать не средствами FS, а средствами СУБД?

Это последний вариант, самый геморойный в моём случае. Я хотел всё упростить, реплицируя только диск и не возиться с mysql master-slave, gluster, и другими тараканами.

начали биться индексы у таблиц
данные в таблицах начали исчезать

Просто интересно, RAM с ECC?

Нет, какой же вывод - что дело в bit flip который произошёл в течение 1.5 дней ? Ну мооооожет быть и да, но вероятность почти нулевая.

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

но вероятность почти нулевая.

вот это ты зря. Опыта с железом мало? Плавающие сбои ОЗУ ничего вообще не ловит, кроме реальной нагрузки.

10+ лет опыта общения с серверами, ниразу не было проблем с ОЗУ.

CoW-файлухи вообще неюзабельны на HDD, тормоза можно нивелировать только жирным кэшем в раме или на тех же ssd

Да, COW значительно, на порядки ускоряет случайную запись, превращая её в линейную, но за это в результате нужно платить скоростью линейного чтения…

Debian bookworm

Насколько там свежий btrfs?

Значит почитал я эту статью https://ar5iv.labs.arxiv.org/html/1707.08514 там действительно всё правильно указано с одним большим НО, о котором говорится в статье. Write amplification из таблички в начале статьи показано при записи одного 4кб блока и сразу sync. То есть они измерили то, что в реальности почти не бывает, чисто академический интерес. А на графике ниже показано, что при записи большего количества данных, write amplification падает до приемлемых значений, в том числе и для BTRFS.

Я измерял похожим образом но для записей по 100*4кб блоков (8кб и +), затем sync, так ближе к реальности. В этой кстати это не измеряли. Я перерыл весь интернет прежде чем начать тесты, думал это уже кто-то проверил, но нет. Вот думаю может статью черкануть, лень только, да и обескуражен неудачей с BTRFS.

так вроде БД и пишут кучей мелких порций, не?

Редко какая БД пишет 4к а потом sync, разве только в финансах где это очень важно, обычно все включают оптимизацию БД при которой изменения пишутся вместе с журналом каждые 5 секунд, а это тысячи 4к блоков…

Также замечу, что есть огромная разница в значении write amplification при наличии и отсутствии снапшота. А также при наличии или отсутствии свободной памяти (в основном актуально для ZFS) Результаты отличаются радикально. Таких тестов я вообще нигде не видел, я первопроходец :)

Не знаю где смотреть её версию, ядро 6.1.0-21-amd64, в modinfo не пишет, btrfs-progs 6.2-1

блин, я из интереса решил помониторить запись на диски и нихрена не понял КАКОГО ЧЁРТА БРАУЗЕРЫ ТАМ ПОСТОЯННО ПИШУТ???

BTRFS

у юзеров стресс, пьют валериану

Предложи им крысиный яд. (%

Убери виртуалку, перепроверь. Несколько нагруженных БД на btrfs живут уже много лет без единого разрыва (c).

А я уже и дефрагментатор для неё новый написал, офигенный, который не жрёт ни диск ни SSD, но видимо не судьба.

Код в студию.

Бэ те ер эф эээээсссс ТУДУДУДУДУДУДУ
У ю зе ров стрееeеесс ДЫДЫДЫДЫ
Предложи им БУЭЭЭЭ РДРДРДЫЩ
Крысиный ЯЯЯЯЯЯЯЯДДД (соло)

10+ лет опыта общения с серверами, ниразу не было проблем с ОЗУ.

С почином! Нет, ты не особенный, и «это меня не коснётся» оставь барчатам.

c онлайн репликацией снапшотами не существует

blksnap посмотри

Да все журналирующие БД так делают. Если данные в принципе не особо важны можно и «включить оптимизацию БД»

Да, на LVM кратно ухудшается запись с обычными снапшотами, но thin должны работать с обычной скоростью. Пару лет назад добавили dm-integrity.

Я хотел всё упростить, реплицируя только диск

А инстанс БД на реплике при этом потушен?

ядро 6.1.0-21-amd64

Это очень древнее ядро.

Обновись хотя бы до последнего LTS.