Обычно на хабре пишут готовые статьи с ответами, но мне хочется поднять вопрос, ответ на который, мне кажется, будет отрицательным.
Суть проблемы: Системы виртуализации с высокой степенью виртуализации (я это говорю, чтобы отмести в сторону openvz) предоставляют место виртуальным машинам в форме виртуального диска. Или, точнее, виртуального блочного устройства. Иногда эмулируется скази (VMWare Server, Virtual PC), иногда «неопределённое блочное устройство», иногда прямым текстом «виртуальный диск» (Xen для PV-машин). Важным является то, что это устройство полностью повторяет свойства блочного устройства — набор секторов, которые можно читать и писать.
Большинство систем виртуализации позволяет изменять размер дисков. Многие системы позволяют это делать на ходу, в онлайне.
Вопрос звучит так: а может ли гостевая ОС воспользоваться этим местом свободно? Этот вопрос выходит за рамки виртуализации и является общим вопросом: есть ли у нас файловые системы, которые способны динамически изменяться в размере в штатном режиме?
Во-первых, нужно сказать, что большинство файловых систем умеет увеличиваться «на ходу». XFS, raiserfs, ext3-4… Некоторые файловые системы могут уменьшаться (ext3, raiser… xfs не умеет). Windows тут выглядит полным ауткастером, так как не поддерживает изменение размера файловой системы NTFS, особенно, на системных дисках. Сторонние утилиты умеют это делать, но не на ходу…
Но даже белая и пушистая ext3 не умеет это делать в штатном режиме. Нужно руками говорить «отресайзить», причём процесс рейсайза (особенно, вниз) занимает огромные ресурсы. По моим личным впечатлениям, на обычных SATA-дисках ресайз с 5.5Тб до 4.5Тб файловой системы с 4Тб занятого пространства занимает около 10-12 часов. Увеличение отрабатывает быстрее, за единицы минут. Но — всё равно с потерей производительности, большой нагрузкой и непозволительно долго.
Да и сам подход неверен. Если мы хотим динамически изменять размер используемого пространства, то нам нужен механизм, который бы добровольно освобождал неиспользуемое пространство, в штатном режиме работы ФС, и запрашивал новое при необходимости.
Насколько я понимаю, таких файловых систем для блочных устройств пока нет. Единственным выходом ялвяется использование file-based network access, иными словами, использование NFS/SMB для юникс и SMB для windows.
Для блочных устройств, насколько я понимаю, частично и ограниченно решён лишь вопрос «увеличения по запросу», это делается с помощью sparsed (разреженного) файла образа диска, который создаётся заведомо большего размера, чем планируется использовать — при записи дополнительной информации на такой диск, он начинает занимать больший объём фактического места. Для гостевой ОС же этот диск размера не меняет (при этом он больше, чем фактически занятое место). Этот метод совершенно не учиывает особенности файловой системы, приводит к фрагментации файла образа и не позволяет отдавать освободившееся место.
Файловая система должна быть минимально возможного размера. Если у нас занято 2Гб, то размер файловой системы 2Гб + служебные данные. Если мы решили создать файл в 100Тб размером, то файловая система запрашивает у блочного устройства нижележащего уровня 25 миллиардов блоков по 4кб и размещает файл. Когда файл сотрут, файловая система отдаст эти 25 миллиардов обратно.
На ум приходит «LVM», но LVM не поддерживает в настоящий момент запросов от файловой системы, да и к вырезанию дыр из середины FS не готов совершенно…
Вопрос 1: существуют ли файловые системы в которых есть подобное решение?
Вопрос 2: как должен выглядеть интерфейс файловой системы и блочных устройств?
Вопрос 3: Можно ли представить себе замену блочных устройств на такой тип виртуальных устройств, который бы с одной стороны позволял создавать и использовать файловые системы, с другой стороны был бы более приспособлен к динамическому изменению размера?
Вопрос 4: как такое устройство будет примерно выглядеть?
Суть проблемы: Системы виртуализации с высокой степенью виртуализации (я это говорю, чтобы отмести в сторону openvz) предоставляют место виртуальным машинам в форме виртуального диска. Или, точнее, виртуального блочного устройства. Иногда эмулируется скази (VMWare Server, Virtual PC), иногда «неопределённое блочное устройство», иногда прямым текстом «виртуальный диск» (Xen для PV-машин). Важным является то, что это устройство полностью повторяет свойства блочного устройства — набор секторов, которые можно читать и писать.
Большинство систем виртуализации позволяет изменять размер дисков. Многие системы позволяют это делать на ходу, в онлайне.
Вопрос звучит так: а может ли гостевая ОС воспользоваться этим местом свободно? Этот вопрос выходит за рамки виртуализации и является общим вопросом: есть ли у нас файловые системы, которые способны динамически изменяться в размере в штатном режиме?
Во-первых, нужно сказать, что большинство файловых систем умеет увеличиваться «на ходу». XFS, raiserfs, ext3-4… Некоторые файловые системы могут уменьшаться (ext3, raiser… xfs не умеет). Windows тут выглядит полным ауткастером, так как не поддерживает изменение размера файловой системы NTFS, особенно, на системных дисках. Сторонние утилиты умеют это делать, но не на ходу…
Но даже белая и пушистая ext3 не умеет это делать в штатном режиме. Нужно руками говорить «отресайзить», причём процесс рейсайза (особенно, вниз) занимает огромные ресурсы. По моим личным впечатлениям, на обычных SATA-дисках ресайз с 5.5Тб до 4.5Тб файловой системы с 4Тб занятого пространства занимает около 10-12 часов. Увеличение отрабатывает быстрее, за единицы минут. Но — всё равно с потерей производительности, большой нагрузкой и непозволительно долго.
Да и сам подход неверен. Если мы хотим динамически изменять размер используемого пространства, то нам нужен механизм, который бы добровольно освобождал неиспользуемое пространство, в штатном режиме работы ФС, и запрашивал новое при необходимости.
Существующие решения
Насколько я понимаю, таких файловых систем для блочных устройств пока нет. Единственным выходом ялвяется использование file-based network access, иными словами, использование NFS/SMB для юникс и SMB для windows.
Для блочных устройств, насколько я понимаю, частично и ограниченно решён лишь вопрос «увеличения по запросу», это делается с помощью sparsed (разреженного) файла образа диска, который создаётся заведомо большего размера, чем планируется использовать — при записи дополнительной информации на такой диск, он начинает занимать больший объём фактического места. Для гостевой ОС же этот диск размера не меняет (при этом он больше, чем фактически занятое место). Этот метод совершенно не учиывает особенности файловой системы, приводит к фрагментации файла образа и не позволяет отдавать освободившееся место.
Что на самом деле нужно
Файловая система должна быть минимально возможного размера. Если у нас занято 2Гб, то размер файловой системы 2Гб + служебные данные. Если мы решили создать файл в 100Тб размером, то файловая система запрашивает у блочного устройства нижележащего уровня 25 миллиардов блоков по 4кб и размещает файл. Когда файл сотрут, файловая система отдаст эти 25 миллиардов обратно.
На ум приходит «LVM», но LVM не поддерживает в настоящий момент запросов от файловой системы, да и к вырезанию дыр из середины FS не готов совершенно…
Вопросы
Вопрос 1: существуют ли файловые системы в которых есть подобное решение?
Вопрос 2: как должен выглядеть интерфейс файловой системы и блочных устройств?
Вопрос 3: Можно ли представить себе замену блочных устройств на такой тип виртуальных устройств, который бы с одной стороны позволял создавать и использовать файловые системы, с другой стороны был бы более приспособлен к динамическому изменению размера?
Вопрос 4: как такое устройство будет примерно выглядеть?
