Виртуалки VirtualBox на btrfs

[@blind_oracle]

Рекомендуют опии монтирования: nodatacow и compress=no.

Как же всё сыро, уж сколько лет варят ее, а всё никуда не годна по сути, если даже на таких элементарных вещах заваливается.
Уж лучше ZFS, у него даже под линуксом практически никаких косяков нет.

[@lolipop]

Зато zfs у вас, без минимум 2гигов памяти выделенных ей, не поедет.

[@blind_oracle]

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

[@AnViar]

Чем же занимается у вас пул на хосте с такой памятью?

[@blind_oracle]

Домашняя файлопомойка + кучка снапшотов\клонов.

[@AnViar]

Ох уж эти сказочники

768 MB is the minimum amount of memory required to install a ZFS root file system.
1 GB of memory is recommended for better overall ZFS performance.

Источник

[@alexyr]

Не всем нужно виртуалки крутить! Для домашнего использования, с возможностью быстрого отката в случае «неправильных» обновлений, самое оно!

[@Disasm]

Для быстрого отката можно и LVM накатить, заодно и легко расширяемые тома получите

[@blind_oracle]

Дело не в виртуалках, а в самой сырости ФС.
Она не должна работать или нет в зависимости от того кручу я на ней виртуалки, качаю гигабайты торрентов или создаю мульён файлов.
Она просто должна работать и не терять данные. Остальное уже вторично.

[@AnViar]

Оптимизацию ФС на характер нагрузки никто не отменял
Про сырость BtrFS-согласен, хотя Oracle уже пустила её в production… да уж…

[@3draven]

Я придерживаюсь мнения, что родное допилят. btrfs для линукса создавалась. К тому же я уверен, что если систему кэширования линукс настроить верно, то и сейчас btrfs будет пахать как миленькая. Ведь вышеописанная штука именно кешем борется, а он в линуксе вполне присутствует и даже не один его вид и способ. Так что скорее всего Oracle знает, что делает. Более того, вероятно это проблема в кэше, а не в ФС, но я конечно ничего не утверждаю. Хотя именно прямая работа с ФС в виртуалбоксе стала причиной косяка. Если через кэш, все пашет как это видно.

[@blind_oracle]

Я придерживаюсь мнения, что родное допилят. btrfs для линукса создавалась.

Да это понятно, что когда допилят — то пожалуйста. Но, пока они пилят, нам, юзерам что делать? :) Правильно, юзать ZFS.

Более того, вероятно это проблема в кэше, а не в ФС

Кэш, он общий и к фс отношение имеет косвенное — другой VFS layer. Поэтому проблема явно не в нём.

[@3draven]

То, что другой слой, конечно ясно. Но, у btrfs есть свои кэши насколько я понимаю, она там свободные блоки кэширует, например. В общем скорее всего там и косяк. Хотя, я вопрос не изучал, я решение искал и нашел :) Так что опять же, ничего утверждать не могу. Плюс ко всему вполне возможно, что btrfs своей архитектурой выявила косяк кэша линуукс… то же себе возможный вариант. В других ФС например могли при прямом обращении к ФС без кеша, по особому обрабатывать транзакции, а в btrfs нет. В общем я это все основываю только на том, что виртуалки с кешем работают не на пять, а на пять с плюсом, грузятся моментом из сохраненного состояния и вообще ни одного нарекания.

[@3draven]

Ну, о zfs я то же думал, но потом посмотрел на ограничения (уж не вспомню какие, давно было) и не стал. Она на линукс перетянута то же не без шероховатостей и их не одна. Может быть это давно было, но меня когда то несколько статей напугали.

[@blind_oracle]

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

[@farcaller]

Copy-on-write, в принципе, плохо совместим с файлами-дисками виртуалок, где постоянно происходят небольшие изменения. Обычно, для этого рекомендуют chattr +C file для отключения CoW для конкретного файла (или директории).

[@xforce]

Тем временем, такой адский комбаин до сих пор не научился ни рейдам с четностями (какие-то эксперементальные реализации только), ни онлайн дедупликации. Зто куча оверхедов, а там, где он мог бы быть полезен — почти бесполезен. В итоге reiser4 и то кажется более оптимальным выбором на текущий момент. Столько пилить базовый функционал, а до сих пор такие грабли…

[@3draven]

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

[@Adnako]

А если в виртуалку подключить btrfs-volume вместо использования vdi-файликов?

[@3draven]

Не знаю как это можно было бы сделать. VMDK можно настроить на раздел диска или весь диск, На btrfs subvolume натравить его не выйдет. Если знаете как, подскажите.

[@Adnako]

Не знаю, я — zfs-адепт, у меня виндовые диски из под kvm на zfs subvolume'ах лежат.

[@larrabee]

btrfs subvolume для ОС выглядят как папки. Использовать их как файлы образов невозможно

[@Adnako]

Т.е. режима raw device в btrfs нету?

[@larrabee]

нету и насколько я знаю не планируется

[@Magister7]

Вижу, не я один, при словах про сжатие, подумал про Reiserfs4…

[@prizzrak]

Ага. На ноутбуке resier4 почти на всех разделах, на /home — в том числе. Пока не было никакх проблем, а уж как /usr/portage сжимается — просто сказка.

[@larrabee]

Использую дома btrfs и на нескольких серверах. Да с дисками виртуалок на жестком диске она работает плохо. Интересно, что на SSD такой проблемы нет и все просто летает. На HDD так-же медленно листятся директории, при большом объеме метаданных. (Винт 4 Тб, метаданных 12 Гб, файлов предположительно около 10 миллионов, lzo сжатие). Выполнение команды ls -l на любой папке тома занимает около секунды -двух). В общем есть куда оптимизировать.
С мнением большинства не соглашусь, btrfs по функционалу достаточно сыра, но стабильна.

[@3draven]

Совершенно про стабильность с вами согласен.

[@3draven]

Конкретно про виртуалки могу сказать, что 3Гб ОЗУ виртуалка восстанавливается из сохраненного состояния теперь за 5сек. Сохраняется за 10сек. Просто на глаз стало быстрее, нажал, еще надоесть не успело и работай. В общем результат переезда достигнут по всем параметрам.