Comments 29
Рекомендуют опии монтирования: nodatacow и compress=no.
Как же всё сыро, уж сколько лет варят ее, а всё никуда не годна по сути, если даже на таких элементарных вещах заваливается.
Уж лучше ZFS, у него даже под линуксом практически никаких косяков нет.
Зато zfs у вас, без минимум 2гигов памяти выделенных ей, не поедет.
Ну конечно, едет нормально.
Если включать дедупликацию — да, нужно больше памяти чтобы контрольные суммы блоков хранить, но тут уж в любой ФС так.
Если включать дедупликацию — да, нужно больше памяти чтобы контрольные суммы блоков хранить, но тут уж в любой ФС так.
Ох уж эти сказочники
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.
Не всем нужно виртуалки крутить! Для домашнего использования, с возможностью быстрого отката в случае «неправильных» обновлений, самое оно!
Для быстрого отката можно и LVM накатить, заодно и легко расширяемые тома получите
Дело не в виртуалках, а в самой сырости ФС.
Она не должна работать или нет в зависимости от того кручу я на ней виртуалки, качаю гигабайты торрентов или создаю мульён файлов.
Она просто должна работать и не терять данные. Остальное уже вторично.
Она не должна работать или нет в зависимости от того кручу я на ней виртуалки, качаю гигабайты торрентов или создаю мульён файлов.
Она просто должна работать и не терять данные. Остальное уже вторично.
Оптимизацию ФС на характер нагрузки никто не отменял
Про сырость BtrFS-согласен, хотя Oracle уже пустила её в production… да уж…
Про сырость BtrFS-согласен, хотя Oracle уже пустила её в production… да уж…
Я придерживаюсь мнения, что родное допилят. btrfs для линукса создавалась. К тому же я уверен, что если систему кэширования линукс настроить верно, то и сейчас btrfs будет пахать как миленькая. Ведь вышеописанная штука именно кешем борется, а он в линуксе вполне присутствует и даже не один его вид и способ. Так что скорее всего Oracle знает, что делает. Более того, вероятно это проблема в кэше, а не в ФС, но я конечно ничего не утверждаю. Хотя именно прямая работа с ФС в виртуалбоксе стала причиной косяка. Если через кэш, все пашет как это видно.
Я придерживаюсь мнения, что родное допилят. btrfs для линукса создавалась.
Да это понятно, что когда допилят — то пожалуйста. Но, пока они пилят, нам, юзерам что делать? :) Правильно, юзать ZFS.
Более того, вероятно это проблема в кэше, а не в ФС
Кэш, он общий и к фс отношение имеет косвенное — другой VFS layer. Поэтому проблема явно не в нём.
То, что другой слой, конечно ясно. Но, у btrfs есть свои кэши насколько я понимаю, она там свободные блоки кэширует, например. В общем скорее всего там и косяк. Хотя, я вопрос не изучал, я решение искал и нашел :) Так что опять же, ничего утверждать не могу. Плюс ко всему вполне возможно, что btrfs своей архитектурой выявила косяк кэша линуукс… то же себе возможный вариант. В других ФС например могли при прямом обращении к ФС без кеша, по особому обрабатывать транзакции, а в btrfs нет. В общем я это все основываю только на том, что виртуалки с кешем работают не на пять, а на пять с плюсом, грузятся моментом из сохраненного состояния и вообще ни одного нарекания.
Ну, о zfs я то же думал, но потом посмотрел на ограничения (уж не вспомню какие, давно было) и не стал. Она на линукс перетянута то же не без шероховатостей и их не одна. Может быть это давно было, но меня когда то несколько статей напугали.
Copy-on-write, в принципе, плохо совместим с файлами-дисками виртуалок, где постоянно происходят небольшие изменения. Обычно, для этого рекомендуют
chattr +C file для отключения CoW для конкретного файла (или директории).
Тем временем, такой адский комбаин до сих пор не научился ни рейдам с четностями (какие-то эксперементальные реализации только), ни онлайн дедупликации. Зто куча оверхедов, а там, где он мог бы быть полезен — почти бесполезен. В итоге reiser4 и то кажется более оптимальным выбором на текущий момент. Столько пилить базовый функционал, а до сих пор такие грабли…
Ну тортеет то она быстро для ФС. Их все подолгу пилят. Пока у нее остался один видимый мне косяк, нежелание работать с большими файлами с кучей мелких изменений… БД и виртуалки, без дополнительных танцев. В остальном, я пользую уже год, даже больше наверное, ни одного косяка. Так что пока я доволен… посмотрю как будет дальше :)
А если в виртуалку подключить btrfs-volume вместо использования vdi-файликов?
Вижу, не я один, при словах про сжатие, подумал про Reiserfs4…
Использую дома btrfs и на нескольких серверах. Да с дисками виртуалок на жестком диске она работает плохо. Интересно, что на SSD такой проблемы нет и все просто летает. На HDD так-же медленно листятся директории, при большом объеме метаданных. (Винт 4 Тб, метаданных 12 Гб, файлов предположительно около 10 миллионов, lzo сжатие). Выполнение команды ls -l на любой папке тома занимает около секунды -двух). В общем есть куда оптимизировать.
С мнением большинства не соглашусь, btrfs по функционалу достаточно сыра, но стабильна.
С мнением большинства не соглашусь, btrfs по функционалу достаточно сыра, но стабильна.
Совершенно про стабильность с вами согласен.
Конкретно про виртуалки могу сказать, что 3Гб ОЗУ виртуалка восстанавливается из сохраненного состояния теперь за 5сек. Сохраняется за 10сек. Просто на глаз стало быстрее, нажал, еще надоесть не успело и работай. В общем результат переезда достигнут по всем параметрам.
Sign up to leave a comment.
Виртуалки VirtualBox на btrfs