LINUX.ORG.RU

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

 , , , ,


1

3

UPD: переехал на btrfs, дальше по тексту устрою небольшой ЖЖ касательно файловой системы, пока не устаканится всё.

Собственно, дано:

16 гигабайт ОЗУ, 4 ядра не молодой амуды, SSD на 250 гигабайт, Терабайтный HDD.

На терабайтник установлен Manjaro KDE (сам в шоке, но всё работает, свистит, не пердит и жрать не просит), на Ext4. Как выяснилось, терабайтник проектировали эстонские инженеры - ну ооочень мееедленно он работает (установка бубунты занимает около 2 (!!!) часов, особенности трахания диска dpkg). Снёс гентушечку с SSD, конвертнул ext4 в ext4 поверх bcache и волосы стали блестящими шелковистыми. Но, как понимаете, понадобилось тут поработать плотненько и...

/dev/bcache0 916G 909G 4,5G 100% /

Своп на SSD, EFI и /boot там же, остальное в одном раздел.

Собственно, пришёл к тому, что моим виртуалочкам, блокчейну, игрушкам и, в последнюю очередь, рабочим коду/документации нужно больше места, а раз так - то не плохо бы попытаться что-то сжать. Ну архивные данные ужал 7z с ультрой, но чет не особо помогло, поэтому подумал, что

Задача:

Не плохо бы организовать прозрачное сжатие ФС. БЕЗ переустановки ОС (мне просто некогда/неохота)/БЕЗ покупки дополнительных винтов. В качестве варианта рассматривается конвертация раздела в btrfs. Периодически железка отрубается по питанию/перегреву (люблю БДСМ - батарейка вторая сдохла вчера, а при вычислительных задачах видеокарты иногда забывается убрать ноут с одеяла).

9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 11698
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 2262

174 Unexpect_Power_Loss_Ct 0x0032 100 100 000 Old_age Always - 571

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

Гуглил. На ЛОРе в последний раз по этому поводу срались почти 3 года назад. Хочу ещё такого срачика.

UPD: места осталось 5 гигабайт. Так вот, как пройдет ребаланс после конвертации? И не будет ли проблем, если я буду включать сжатие? Чет как-то по-моему, из-за особенностей CoW эти 5 гигабайт свободных не хватит нифига, или нет?

Deleted

Последнее исправление: Deleted (всего исправлений: 3)

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

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

SR_team ★★★★★
()
Ответ на: комментарий от SR_team

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

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

alex_sim ★★★★
()
Ответ на: комментарий от greenman

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

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

Deleted
()
Ответ на: комментарий от SR_team

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

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

Deleted
()
Ответ на: комментарий от greenman

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

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)

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

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

i586 ★★★★★
()
Ответ на: комментарий от i586

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

Deleted
()
Ответ на: комментарий от Deleted

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

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

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

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

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

greenman ★★★★★
()
Последнее исправление: greenman (всего исправлений: 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 /
Rx0
()
Последнее исправление: Rx0 (всего исправлений: 1)

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

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

slimsim
()
Ответ на: комментарий от greenman

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

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

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

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

Device Model: TOSHIBA MQ01ABD100

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)

После двух лет тестовой обкатки, сам недавно перевёл последний бастион 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 \;

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

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

aidaho ★★★★★
()
Последнее исправление: aidaho (всего исправлений: 2)
Ответ на: комментарий от Deleted

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

greenman ★★★★★
()

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

Rx0
()
Ответ на: комментарий от Deleted

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

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 3)

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

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

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от SR_team

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

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

Deleted
()
Ответ на: комментарий от intelfx

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

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

Deleted
()

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

darkenshvein ★★★★★
()
Ответ на: комментарий от Deleted

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

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Deleted

У меня bcache во writeback

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Deleted

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

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от intelfx

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

i-rinat ★★★★★
()
Ответ на: комментарий от intelfx

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

Deleted
()
Ответ на: комментарий от i-rinat

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

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

Deleted
()
Ответ на: комментарий от SR_team

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

Deleted
()
Ответ на: комментарий от Deleted

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от intelfx

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

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

Deleted
()
Ответ на: комментарий от Deleted

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

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

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

SR_team ★★★★★
()

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

Deleted
()
Ответ на: комментарий от Deleted

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

Deleted
()
Ответ на: комментарий от Deleted

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

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

Rx0
()
Ответ на: комментарий от Rx0

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

Deleted
()
Ответ на: комментарий от Deleted

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

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

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

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

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

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

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

Deleted
()
Ответ на: комментарий от Deleted

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

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от i-rinat

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

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.