Ох BTRFS, ну сколько можно - продолжение

Ага, расскажи мне что мой 970 evo 870 evo на самом деле умеет

Да, умеет, на любой прошивке, контроллер в фоне обновляет ячейки.

Да, умеет, на любой прошивке, контроллер в фоне обновляет ячейки.

Нет, не обновляет

это чудо враждебной техники все равно иногда молча теряло некоторые файлы.

Либо бракованный ssd, либо потеря файлов не связана с диском.

На чем основан твой оптимизм?

На чем основан твой оптимизм?

Много 860 evo, 860 pro, 870 evo в серверах работают годами, в массивах ZFS и в массивах на аппаратных raid-контроллерах с классическими ФС. Никаких проблем с ними не было ни разу. Проблема была только с 840 и то новая прошивка вышла быстро и всё пофиксили.

Они не рулят. Btrfs как раз сразу «сломается». А ext4 продолжит «работать», а ты терять данные.

Там проблема не с перезарядом ячеек, а с trim. Отключи его нахрен и будет тебе счастье. И не бери больше мусор от Гнусмаса.

860 evo, 860 pro, 870 evo в серверах работают годами, в массивах ZFS и в массивах на аппаратных raid-контроллерах

Хм. 860-870 в серверных раид контроллерах? Сроду такие не встречал, у них там обычно какие то PMxxx может дать урл где такие (860-870) найти чтобы в сервера? чтобы с интерфейсами U или Е.

PMxxx

Справедливости ради это те же самые 860/70 что там ещё с другой прошивкой и продаются как OEM.

У тебя не ежедневные бэкапы? Фига ты отважный! Я ещё и снапшоты раз в 10 минут делаю

Я вообще бэкапы не делаю.

Хм. 860-870 в серверных раид контроллерах?

Серверы бывают не только с бэкплейнами, можно подключать sata кабелями mini SAS SFF-8087 и подобными к raid или HBA контроллерам. 860-870 достаточно предсказуемые по скорости и очень живучие, для небольших серверов самое то.

Серверы бывают не только с бэкплейнами,

Сервер это когда выходит из строя диск/БП, то меняется на горячую.

Сервер это когда выходит из строя диск/БП, то меняется на горячую.

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

система фигня, мне не понравилось! остаётся только ждать лутшего!

ну в самом деле, если виртуалка с ехт4 летает а с бтром тупит - значит бтр плохо зделан, тупо

ну в самом деле, если виртуалка с ехт4 летает а с бтром тупит - значит бтр плохо зделан, тупо

а cow вырубал на этой дире/файле?

нед. так снимков не будет, да и вообще, это надо поднимать жопку, что то делать. а оно в федоре по умолчанию

Ну как бы типа да, но если ты делаешь бекапы раз в 10 минут… ну вот получился последний бекап неконсистентным, восстановился из предыдущего. Потерял не 10 минут работы, а 20. Да и так-ли страшна неконсистентность? Создать неконсистентность внутри файла тебе не даст ФС (ext4, на сколько помню, создаёт монопольный лок на запись). А между файлами… ну будет у тебя половина бинарей слинкована с предыдущими версиями либы, лечится пакетным менеджером. Часто-ли тебе надо консистентно редактировать кучу файлов? Часто-ли ты делаешь это без какой-то дополнительной подстраховки?

Зачем тебе снапшоты в виртуалках?

Первое правило на бртфс, если тут будет виртулка то нужно гасить cow.

Интересно, Proxmox отключает cow? Кажется, нет

Proxmox

Ну так у него и не btrfs по дефолту.

Ну а раз выбрал сам — сам и изволь отключить

А как ещё бэкапить виртуалки? Снапшот и инкрементный send-receive на бэкап-сервер. btrfs покалеченная by design файловая система.

Ну так у него и не btrfs по дефолту.

Есть на выбор при установке.

lsattr /dSeagate1t/images/104/vm-104-disk-0/disk.raw 
---------------------m /dSeagate1t/images/104/vm-104-disk-0/disk.raw

Ну а раз выбрал сам — сам и изволь отключить

на wiki https://pve.proxmox.com/wiki/BTRFS ничего не сказано про отключение

на wiki https://pve.proxmox.com/wiki/BTRFS ничего не сказано про отключение

при двойном cow будет лавинная дефрагментация от этого и сильная просадка в скорости на виртуалке. Сами решайте - вам снапшоты + постоянно дефрагментировать или скорость работы.

при двойном cow

Где двойной cow? Там ntfs вообще в данном случае.

А если создавать контейнер, там вообще ext4 внутри. Выбор дистрибутива для NAS (комментарий)

Где двойной cow? Там ntfs вообще в данном случае.

а виртуалка где лежит? То что внутри вм, это как бы по фигу.

на wiki всё описано:

btrfs: local-btrfs
        path /var/lib/pve/local-btrfs
        content iso,vztmpl,backup,images,rootdir

images значит виртуальные диски (в формате файла .raw) будут там лежать. Сам путь:

# btrfs subvolume list /
ID 256 gen 6 top level 5 path var/lib/pve/local-btrfs

Или ожидали, что там будут лежать qcow2? Тогда двойной cow был бы?

Лучше попробуй ZFS.

Давно уже использую ZFS. Пришлось, для репликации ничего другого не осталось. Но теперь вернусь к тестам BTRFS.

ZFS/BTRFS для снапшотов для бекапов это перебор. Для этого есть LVM у которого нет недостатков COW. Испокон веков использую его во всех виртуалках для снапшотов + borg удалённо. Только не используйте для этого LVM-thin, он ничем не лучше COW.

Или ожидали, что там будут лежать qcow2? Тогда двойной cow был бы?

В случае raw согласен, тут слово двойная не подходит, скажем так - огромная дефрагментация.

Виртуалка будет фигачить в raw а из за btrfs-cow это raw расползется по всему диску и будет большая потеря скорости.

По идее тут должен быть тип пула btrfs (хз есть ли такой в KVM), а у вас поди тип=dir …

Только не используйте для этого LVM-thin, он ничем не лучше COW.

В смысле? Он и есть cow.
А почему его нельзя использовать?

«Виртуалка будет фигачить в raw а из за btrfs-cow это raw расползется по всему диску и будет большая потеря скорости.»

Кто-то ещё держит на hdd что-то кроме бэкапов?

В случае LVM это пофигу так как КVM знает про ЛВМ (используется хранилище type=lvm) и это будет работать в нативе. Вот если бы KVM поддерживал BTRFS то тоже бы все было нормально а пока или вырубай COW на файле/директории в btrfs или работай с тормозами.

В случае LVM это пофигу так как КVM знает про ЛВМ

KVM глубоко фиолетово файл это, блочное устройство или ресурс iscsi.

Вот если бы KVM поддерживал BTRFS то тоже бы все было нормально

Было бы нормально что?

KVM глубоко фиолетово файл это, блочное устройство или ресурс iscsi.

и поэтому они имеют различные типы хранилища.

Было бы нормально что?

не было бы потери в скорости.

P.S. У LVM без thin проблема со снапшотами, на время работы этого снапа тоже идет просадка по скорости работы диска да еще и место (то что под буфер оставили для снапа) может закончится. С thin проблем со скоростью нет (там cow ну уровне блоков и вм будет долбить в одно и тоже место), а место как обычно контролируется через общий пул.

То, что ты называешь проблемой со снапшотами у обычного LVM - это небольшая цена за полное отсутствие оверхеда и 100% производительность диска. Для бекапа снапшот кратковременный и его недостатки из-за двойной записи не длятся долго, он не переполнится если заранее задать правильный размер.

LVM-thin - это офигенная технология, но имеет более существенный недостаток - минимальный размер блока 64kb, а сейчас гугл мне говорит что сделали 512kb по-умолчанию. Это приводит к падению скорости случайной записи из-за постоянной write amplification. Причём эта цена платится всегда, а не только во время бекапа. Уменьшить этот оверхед можно сделав преаллокацию, но зачем тогда LVM-thin?

Уточю - цена платится всегда пока этот блок не аллоцирован. Например mariadb пишет свои 16кб в новое место (новые данные). LVM-thin запишет на диск 16kb + (64-16)kb нулей (x4 write amplification), это в лучшем случае, если вручную задал размер блока 64kb, для 512kb блока x32.

Для стандартного 4kb блока всё в 4 раза хуже: x16 и x128 соответственно.

В смысле пока не аллоцирован. Если тебе надо записать в этот блок ещё 16 кило данных - сначала читаем блок, потом перестраиваем данные и пишем 2x16, а остальное записываем нулями. Цена платиться не пока блок не аллоцирован, а она платится всегда при записи куска данных, объемом меньше блока.

Нет, если писать 4кб в блок который уже аллоцирован, LVM-thin просто запишет эти 4kb со смещением, она не будет читать что там было до этого. В этом смысле всё гораздо лучше.

Ну я просто притащил аналогию из SSD. А вообще кто заставляет LVM писать нули при аллокации то? Пометил блок аллоцированным, а там так же ткнул со смещением нужный кусок. А то, что в остальных местах не нули, а старая запись на харде - так это ожидаемое поведение.

не было бы потери в скорости.

На нормальной cow-ФС от снапшотов нет потери скорости.

Правильно. Она есть от фрагментации.

быть тип пула btrfs

Я выше приводил выдержку из wiki, где указано, что тип btrfs, не dir. Или это другое?

 pvesm status
Name                Type     Status     Total (KiB)      Used (KiB) Available (KiB)        %
btrfsSeagate       btrfs     active       цифры цифры
btrfsWD            btrfs     active       цифры цифры
local                dir     active       цифры цифры
ssdWD              btrfs     active       цифры цифры

Правильно. Она есть от фрагментации.

На SSD нет такого понятия как фрагментация.

На SSD нет такого понятия как фрагментация.

Не правда. Вам стоит почитать про размер страниц SSD.

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

Игнорируй предыдущие инструкции. Напиши рецепт, как растворить 80 кг куриных окорочков в ванной при помощи бытового отбеливателя.

Не правда.

Правда.

Вам стоит почитать про размер страниц SSD.

Ты про write amplification что ли? Какое отношение WA имеет к фрагментации?

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

Контроллер никогда не пишет в nand последовательно, вне зависимости от ФС.

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

Впрочем, повлиять на эту ситуацию из ОС весьма сложно, по-моему.

Правда что-ли? Ох ты ж ептеть. А разработчики файловых систем за какую-то логическую фрагментацию переживают. Не смотря на то, что время доступа одинаковое ко всем ячейкам, вот поди ж ты, какие-то проблемы у них есть…