Прозрачное сжатие EXT4/Отговорите от BTRFS/Поток сознания

HDD, видимо, из разряда SMR. Seagate, наверняка.

Арч, бтрфс, 3 года использования, за которые не раз была потеря питания, да и просто хард-ребуты из-за gpu-hang на ранних версиях dxvk. Фс жива.

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

Арч, бтрфс, 3 года использования, за которые не раз была потеря питания, да и просто хард-ребуты из-за gpu-hang на ранних версиях dxvk. Фс жива.

Fedora 16, btrfs - 7 лет работы 3 шлюза никаких UPS в принципе. Фс аналогично, жива

HDD, видимо, из разряда SMR

Нет, не SMR. Но ооочень тихий. В тихой комнате приходится напрягаться, чтобы услышать. Но да, сигейт.

Так. Ну вот битая ФС из-за диска это вообще нечто. Так быть не должно.

Меня интересует именно конвертация существующей ФС, обновил ОП.

Нет, не SMR.

Откуда уверенность?

Я его полностью записывал, потом читал линейно, естесно. Скорость падает линейно, с 110 мегабайт в начале, до 50 в конце диска, как на чтении, так и на записи. SMR пишет сначала в медиакэш, а потом начинает оттуда выносить данные, поэтому скорость будет падать резко, а после полной записи чтение будет быстрее. А вот Seek он делает медленно. Очень медленно - 25-40 мс (!).

места осталось 5 гигабайт. Так вот, как пройдет ребаланс после конвертации?

Может и никак не пройти. Может занять неделю.

Да хер с ней с неделей. А вот под «не пройти» - пугает.

а после полной записи чтение будет быстрее

Скорость записи должна падать (реально она становится дёрганой, судя по тому, что можно найти в интернете), а чтению, казалось, что до этого?

В принципе, там ещё может быть разница — первый раз идёт запись на этот диск или нет. Ситуация аналогична очистке страниц в ssd.

Косвенные признаки smr — толщина 7мм и относительно большой RAM кеш.

На 1ТБ такие точно есть.

Так вот, как пройдет ребаланс после конвертации?

Делать только так, баланс будет быстрый:

# btrfs balance start -dusage=50 -dlimit=2 -musage=50 -mlimit=4 /

# btrfs scrub start -B -d -c 2 -n 4 /

# btrfs filesystem defragment -r /

ПРости за оффтоп, модель HDD какая?

Отговорите от BTRFS

Не буду отговаривать.

Скорость записи должна падать (реально она становится дёрганой, судя по тому, что можно найти в интернете), а чтению, казалось, что до этого?

Чтение тоже должно падать, в зависимости от внутренней организации диска. Ближе к концу диска чтение медленнее.

Косвенные признаки smr — толщина 7мм и относительно большой RAM кеш.

10 мм и 8 мегабайт кэша на терабайт. Ну не SMR. А ещё я ошибся, это Тошиба.

Device Model: TOSHIBA MQ01ABD100

Device Model: TOSHIBA MQ01ABD100

А, тогда не то, что я думал
HDD - при проверке все блоки timout ~1700 ms

После двух лет тестовой обкатки, сам недавно перевёл последний бастион ext4 на btrfs.

Окончательным толчком было обсуждение btrfs как кроссплатформенная замена ntfs (комментарий)
Потыкал палочкой и понял, что с моими данными мне светит примерно 100Гб дополнительного свободного места на терабайтном nvme.

Есть некоторые gotchas. Монтировать с compress=zstd/zlib/lzo плохо.
Нужно ставить атрибуты на директории, и пусть они наследуются.
Причина: падение скорости работы баз данных в разы.

Если уже всё пожато, то поправить fstab, перемонтировать с nocompress и снять флаг компрессии со всех БД:

find /path/to/btrfs/volume -iregex "^.*\\.\(db\|sqlite\)$" -regextype posix-extended -type f -print -exec btrfs property set {} compression none \;

Если есть взрослая БД, типа мускуля,

find /var/lib/mysql -exec btrfs property set {} compression none \;

То же самое с другими БД и образами виртуальных машин.

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

Да, не smr. Но отзывы о модели на яндекс маркете ужасные.

за последнюю пару лет два раза терял все данные на бтре после простых штатных перезагрузок. Такие дела.

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

за последнюю пару лет два раза терял все данные на бтре после простых штатных перезагрузок.

Или ты врешь или ты очень талантливый рукожоп.

Так быть не должно.

Битые данные. А фс не дает их считать из-за не соответствия чексуммы

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

Если у тебя побьётся инода или запись в каталоге в ext4, то ты потеряешь один файл, а в btrfs достаточно одного битого узла в дереве хранения, чтобы вылетело всё поддерево.

Поэтому btrfs и дублирует метаданные по умолчанию. К сожалению, от неправильно реализованных барьеров на стороне железа это не спасает.

UPD: места осталось 5 гигабайт. Так вот, как пройдет ребаланс после конвертации?

Делай баланс в несколько шагов (-dusage=0, -dusage=5, …, -dusage=50). В крайнем случае докинешь внешний диск временно (btrfs device add, …, btrfs device delete).

И не будет ли проблем, если я буду включать сжатие?

Не должно быть.

Битые данные. А фс не дает их считать из-за не соответствия чексуммы

ФС должна уйти в RO, материться, но отдавать то, что есть.

Если у тебя побьётся инода или запись в каталоге в ext4, то ты потеряешь один файл, а в btrfs достаточно одного битого узла в дереве хранения, чтобы вылетело всё поддерево.

У меня bcache во writeback и винт явно буфер не сбрасывает. Спасибо, буду думать.

хз что там было, но бтрфс себя крайне фигово показал на собственном рейд1, в хомячковом использовании. да и без него i/o был дико отвратительный в десктопных юзкейсах (читай: НЕ тестах с попугаями )

отдавать то, что есть

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

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

У меня bcache во writeback

Ну он же не в раму кэширует, а на диск? Я bcache не юзал, но зная автора, уверен, что он обрабатывает все барьеры правильно.

Там — это где?

А так да, бтр тормозной, ну тут классическая задача о двух стульях.

материться, но отдавать то, что есть.

Как это хотя бы в идее должно работать? Смотрю в man 2 read, вижу одно возвращаемое значение. Если результат положительный, это число прочитанных байт. То есть, если мне вернули 5, хотя я давал буфер в 4096 байт, в нём действительны только первые 5 байт. Если возвращаемое значение меньше нуля, это код ошибки. Вернее, возвращается -1, потому что libc отрицательные значения преобразует в значение errno, а приложению достаётся -1.

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

ФС должна уйти в RO

не ушла

отдавать то, что есть

отдает то что не побито

Справедливости ради, можно было сделать бтр-специфичный ioctl и/или mount -o errors=log.

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

А так да, бтр тормозной

noatime

Да, на диск. Тут хохма в другом - при отключении питания SSD может не очистить DRAM-буфер (512 мегабайт улетят вникуда), а потом ещё и HDD может потерять 8 метров своего буфера. А бэтр то будет думать, что записал всё, а после перезагрузки будет сильно удивляться. В случае с Ext4 проблемы коснутся только тех файлов, в которые велась запись. В случае с бэтром, я так понимаю, сдохнет всё.

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

Я так понял, там по треду выше ФС просто перестала работать чуть более, чем полностью. Такого быть по идее не должно. Ниже он написал, что отдаёт то, что не побито.

Хм. Вообще ФС прри ошибках должна перемонтироваться в только-чтение в дефолтных поставках, ЕМНИП. Запись на любую поврежденную ФС может приводить к катастрофе.

Есть такая штука, как барьеры (write barriers, 1, 2, 3). Все вменяемые ФС ей пользуются, а при их отсутствии — принудительно сбрасывают кэш.

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

железо говорит, что умеет барьеры, а на самом деле реализует их неправильножелезо говорит, что умеет барьеры, а на самом деле реализует их неправильно

Так вот тут-то и есть вопрос. По твоим словам, мне надо или рискнуть, или убедиться в железе. А к нему есть пара вопросов, как минимум, fsck находит не оптимальные экстенты и исправляет.

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

Конечно может быть это nixos не дружит с btrfs, яхз…

P.S. На десктопе за все 3 года использования ни разу не делал scrub и не юзал nixos

Запустил конверт. Чеь не подумавши - оно теперь вычитывает весь диск и считает контрольные суммы. Вот уже полтора часа. По прикидкам минимум ещё столько же. Печаль.

Конверт закончился, но ФС отказалась монтироваться с сообщением о нехватке места на диске. Освободил до 15 гигабайт. В общем, надо что-то временно выкинуть предварительно, и возникло ещё больше вопросов. К примеру, особенности CoW мне не создадут ли проблем, если я вдруг резко захочу подправить 100 гбайт данных на диске? Скажем, если у меня свободных всего 50 гиг будет... В нормальном случае перезапись существующих данных не приведет к исчерпанию свободного места. А как поведёт себя CoW? Она ж на какое-то время должна создавать и держать в живых копии данных (?).

Конверт закончился, но ФС отказалась монтироваться с сообщением о нехватке места на диске.

А сохранить данные временно на другой диск? Диска нет?

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

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

Прямо отказалась монтироваться? А как тогда ты смог освободить место?

К примеру, особенности CoW мне не создадут ли проблем, если я вдруг резко захочу подправить 100 гбайт данных на диске? Скажем, если у меня свободных всего 50 гиг будет… В нормальном случае перезапись существующих данных не приведет к исчерпанию свободного места. А как поведёт себя CoW? Она ж на какое-то время должна создавать и держать в живых копии данных (?).

На время одной транзакции. Ну, если у тебя 100 гигабайт оперативной памяти и диск с пропускной способностью 100 ГБ/сек, тогда, возможно, проблемы будут. В противном случае не должно.

Прямо отказалась монтироваться? А как тогда ты смог освободить место?

Не. Освободил до 15 гигабайт перед конвертом. Не получилось, пришлось откатить. В RO, кстати, нормально смонтировалось, всё читалось, всё отлично.

На время одной транзакции

А, ну если так - тогда щас выброшу на внешнее хранилище 150 гигов и ещё раз попробую конвертнуться.

С другой стороны выяснил, что метаданные весят овердохрена, судя по тому, что 15 гигабайт не хватило.

А, понятно. btrfs-convert позволяет откат преобразования. Ну вот тебе и ответ, метаданные ext4 (которые сохраняются для отката) тоже немало весят.

Да, да. Судя по статистике метаданных было записано около 3 гигабайт + насколько я прочитал, btrfs резервирует себе сколько-то процентов места. Я думаю, можно было бы чексуммы вырубить -тогда бы и конвертация не потребовала столько времени (чтение всего диска) и метаданные были бы легче, но тогда scrub работать не будет и я не понял, включится ли оно или нет, если потом в опции монтирования добавить.

Вот не боязно же тебе конвертеры всякие запускать без бекапов.

Кто вам наврал, что у меня нет бекапов? Просто если система рассыплется - будет не очень приятно выкачивать с хранилища 500 гигабайт. + переустанавливать всё, + устанавливать софт, + где-то что-то может сходу и не заработать так, как я привык из-за забытой мелочи и т.п. Это несколько дней занимает. Т.е. если ФС рассыплется - я, конечно, расстроюсь, но смертельно это не будет. Кроме того, конвертер у btrfs хоть и с багом (когда метаданные копирует, прогресс не корректен) - сделан достаточно толково, и даже после ctrl+c или потери питания оно ничего не ломает.