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

    Много времени прошло с момента когда появилась btrfs. Она еще в разработке. Плюсов заявлено и уже реализовано море. Тут тебе и сжатие прозрачное и снимки одной командой и еще множество плюшек. Пока нет онлайн дефрагментации, но все же хочется попользовать. На root своего ноута-десктопа давно пользую, уже наверно год. Снапшоты спасают от ломаных пакетов и прочего подобного. У одного знакомого на мининоуте еще дольше, так как на его SSD встроенный ничего толком не влазит, а тут сжатие прозрачное. В общем довольно стабильна эта ФС сегодня.

    Решил я на нее наконец то перетащить свой том с данными. Множество текстовых файлов какие то архивы с исходниками и прочее подобное сжатием пожмется, а по скорости btrfs то же неплоха. Решил да сделал. Все просто отлично конвертировалось, потом дефрагментация, балансировка дерева и свободного места на жестком диске стало на 100Гб больше чем было. Цель была не в свободном месте, его и так меньше чем 200Гб давно не бывало, цель была в скорости доступа. Мощный процессор даже не замечает нагрузки от сжатия данных, но на винте то этих данных в результате хранится в два раза меньше. Отсюда меньше нагрузка на винт и выше скорость доступа. Кстати, если будете переводить ФС на чем то, не конвертируйте, а просто создайте пустую и туда все скопируйте. Дело в том, что дефрагментация и балансировка дерева очень долго идут, а винт все это время пашет как проклятый. Лучше уж временно слить данные на промежуточный и потом обратно.
    В общем радовался я, но не долго. У меня на этом томе лежат образы виртуалок нескольких, с ними удобно. Проц (i7) виртуализацию поддерживает, а виртуалки для экспериментов очень полезны. Но на btrfs они отказались работать категорически. Начались какие то бесконечные дисковые операции и все, виртуалка висит что то там переваривая, я не дождался ни разу когда же закончит.
    Естественно я полез искать решение. Рекомендуют опии монтирования: nodatacow и compress=no. Это отключит сжатие томов и CoW режим (самое счастье от этой ФС, помимо снапшотов и прочих RAID-остей), так что меня категорически не устроило. Плюс ко всему даже с этими опциями btrfs и виртуалки (VirtualBox) не уживались нормально все равно. Это конечно недоработка в ФС, не стану тут ее выгораживать.
    Как выяснилось, все можно решить не внутри btrfs, а внутри VirtualBox-а! Достаточно включить кэширование в настройках носителя виртуалки и все отлично пашет и со сжатием, и в CoW режиме btrfs. Хотя вроде бы в документации на VirtualBox пишут, что виртуальный SATA контроллер не нуждается в кешировании, в данном случае оно спасает.

    image

    P.S. Да, грузятся виртуалки теперь действительно намного шустрее, что и требовалось изначально.

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 29

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

      Как же всё сыро, уж сколько лет варят ее, а всё никуда не годна по сути, если даже на таких элементарных вещах заваливается.
      Уж лучше ZFS, у него даже под линуксом практически никаких косяков нет.
        0
        Зато zfs у вас, без минимум 2гигов памяти выделенных ей, не поедет.
          0
          Ну конечно, едет нормально.
          Если включать дедупликацию — да, нужно больше памяти чтобы контрольные суммы блоков хранить, но тут уж в любой ФС так.
            0
            Чем же занимается у вас пул на хосте с такой памятью?
              0
              Домашняя файлопомойка + кучка снапшотов\клонов.
            0
            Ох уж эти сказочники
            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.
            Источник
            0
            Не всем нужно виртуалки крутить! Для домашнего использования, с возможностью быстрого отката в случае «неправильных» обновлений, самое оно!
              0
              Для быстрого отката можно и LVM накатить, заодно и легко расширяемые тома получите
                +1
                Дело не в виртуалках, а в самой сырости ФС.
                Она не должна работать или нет в зависимости от того кручу я на ней виртуалки, качаю гигабайты торрентов или создаю мульён файлов.
                Она просто должна работать и не терять данные. Остальное уже вторично.
                  0
                  Оптимизацию ФС на характер нагрузки никто не отменял
                  Про сырость BtrFS-согласен, хотя Oracle уже пустила её в production… да уж…
                    +1
                    Я придерживаюсь мнения, что родное допилят. btrfs для линукса создавалась. К тому же я уверен, что если систему кэширования линукс настроить верно, то и сейчас btrfs будет пахать как миленькая. Ведь вышеописанная штука именно кешем борется, а он в линуксе вполне присутствует и даже не один его вид и способ. Так что скорее всего Oracle знает, что делает. Более того, вероятно это проблема в кэше, а не в ФС, но я конечно ничего не утверждаю. Хотя именно прямая работа с ФС в виртуалбоксе стала причиной косяка. Если через кэш, все пашет как это видно.
                      0
                      Я придерживаюсь мнения, что родное допилят. btrfs для линукса создавалась.

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

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

                      Кэш, он общий и к фс отношение имеет косвенное — другой VFS layer. Поэтому проблема явно не в нём.
                        0
                        То, что другой слой, конечно ясно. Но, у btrfs есть свои кэши насколько я понимаю, она там свободные блоки кэширует, например. В общем скорее всего там и косяк. Хотя, я вопрос не изучал, я решение искал и нашел :) Так что опять же, ничего утверждать не могу. Плюс ко всему вполне возможно, что btrfs своей архитектурой выявила косяк кэша линуукс… то же себе возможный вариант. В других ФС например могли при прямом обращении к ФС без кеша, по особому обрабатывать транзакции, а в btrfs нет. В общем я это все основываю только на том, что виртуалки с кешем работают не на пять, а на пять с плюсом, грузятся моментом из сохраненного состояния и вообще ни одного нарекания.
                0
                Ну, о zfs я то же думал, но потом посмотрел на ограничения (уж не вспомню какие, давно было) и не стал. Она на линукс перетянута то же не без шероховатостей и их не одна. Может быть это давно было, но меня когда то несколько статей напугали.
                  0
                  На данный момент она уже стабильна как танк и работает без глюков. В матёром продакшене не пробовал, потребности особой нет, а дома пашет уже несколько лет (тогда она еще считалась нестабильной) безо всяких шероховатостей. Активно юзаю снапшоты и клоны для бэкапов, компрессию тоже.
                0
                Copy-on-write, в принципе, плохо совместим с файлами-дисками виртуалок, где постоянно происходят небольшие изменения. Обычно, для этого рекомендуют chattr +C file для отключения CoW для конкретного файла (или директории).
                  0
                  Тем временем, такой адский комбаин до сих пор не научился ни рейдам с четностями (какие-то эксперементальные реализации только), ни онлайн дедупликации. Зто куча оверхедов, а там, где он мог бы быть полезен — почти бесполезен. В итоге reiser4 и то кажется более оптимальным выбором на текущий момент. Столько пилить базовый функционал, а до сих пор такие грабли…
                    0
                    Ну тортеет то она быстро для ФС. Их все подолгу пилят. Пока у нее остался один видимый мне косяк, нежелание работать с большими файлами с кучей мелких изменений… БД и виртуалки, без дополнительных танцев. В остальном, я пользую уже год, даже больше наверное, ни одного косяка. Так что пока я доволен… посмотрю как будет дальше :)
                      0
                      А если в виртуалку подключить btrfs-volume вместо использования vdi-файликов?
                        0
                        Не знаю как это можно было бы сделать. VMDK можно настроить на раздел диска или весь диск, На btrfs subvolume натравить его не выйдет. Если знаете как, подскажите.
                          0
                          Не знаю, я — zfs-адепт, у меня виндовые диски из под kvm на zfs subvolume'ах лежат.
                          0
                          btrfs subvolume для ОС выглядят как папки. Использовать их как файлы образов невозможно
                            0
                            Т.е. режима raw device в btrfs нету?
                              0
                              нету и насколько я знаю не планируется
                      +1
                      Вижу, не я один, при словах про сжатие, подумал про Reiserfs4…
                        0
                        Ага. На ноутбуке resier4 почти на всех разделах, на /home — в том числе. Пока не было никакх проблем, а уж как /usr/portage сжимается — просто сказка.
                        0
                        Использую дома btrfs и на нескольких серверах. Да с дисками виртуалок на жестком диске она работает плохо. Интересно, что на SSD такой проблемы нет и все просто летает. На HDD так-же медленно листятся директории, при большом объеме метаданных. (Винт 4 Тб, метаданных 12 Гб, файлов предположительно около 10 миллионов, lzo сжатие). Выполнение команды ls -l на любой папке тома занимает около секунды -двух). В общем есть куда оптимизировать.
                        С мнением большинства не соглашусь, btrfs по функционалу достаточно сыра, но стабильна.
                          0
                          Совершенно про стабильность с вами согласен.
                            0
                            Конкретно про виртуалки могу сказать, что 3Гб ОЗУ виртуалка восстанавливается из сохраненного состояния теперь за 5сек. Сохраняется за 10сек. Просто на глаз стало быстрее, нажал, еще надоесть не успело и работай. В общем результат переезда достигнут по всем параметрам.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое