Организация FreeBSD Foundation объявила (http://freebsdfoundation.blogspot.com/2012/03/new-funded-pro...) о выделении денежного гранта на реализацию возможности увеличения размера файловой системы без размонтирования дискового раздела. Поддержка расширения разделов на лету будет обеспечена для файловых систем UFS и ZFS, для чего будет подготовлен новый GEOM-класс и внесены необходимые изменения в код ФС. Указанная возможность позволит существенно упростить поддержание виртуализированных окружений на базе FreeBSD.
Грант предоставлен Эдварду Томашу Наперала (Edward Tomasz Napierala), уже получавшему финансирование за создание реализации контейнеров ресурсов и механизма ограничения ресурсов для отдельных Jail-окружений. Работу планируется завершить до октября 2012 года.URL: http://freebsdfoundation.blogspot.com/2012/03/new-funded-pro...
Новость: http://www.opennet.me/opennews/art.shtml?num=33288
очень круто.
пока правда не знаю где применить, но вполне неплохой задел если на одном из разделов кончилось место
> очень круто.
> пока правда не знаю где применить, но вполне неплохой задел если на
> одном из разделов кончилось местоВ виртуальных окружениях место можно увеличивать сколько угодно.
хотелось бы и уменьшения так же
> хотелось бы и уменьшения так жеВыделяйте грант!
Хотелось бы уменьшения *хотя бы* для не примонтированной FS UFS
>Поддержка расширения разделов на лету будет обеспечена для файловых систем UFS и ZFSА ZFS разве так не умеет?
>>Поддержка расширения разделов на лету будет обеспечена для файловых систем UFS и ZFS
> А ZFS разве так не умеет?Умеет. Неясно что они этим хотели сказать.
Ну, либо распил грантов, либо LVM-а хотят. ///И меня, конечно, поправят!
Может не они, а горе-переводчик новости.
> Может не они, а горе-переводчик новости.В оригинал заглянуть слабо ?
"This project will add GEOM and filesystem changes that are necessary to increase the size of both UFS and ZFS filesystems while a filesystem is mounted read-write."Увеличение размера ФС будет производиться одновременно с увеличением образов виртуальных машин. По сути задача для ZFS сводится к увеличению размера "диска", на котором размещён раздел, сам по себе ZFS не узнает, что диск стал больше, хоть он уже и умеет расширение без отмонтирования.
> Умеет. Неясно что они этим хотели сказать.Afaik, ZFS умеет только менять размеры "подсистем" (т.е., фактически, квоты на отдельные каталоги), но не может увеличивать размер физического тома.
>> Умеет. Неясно что они этим хотели сказать.
> Afaik, ZFS умеет только менять размеры "подсистем" (т.е., фактически, квоты на отдельные
> каталоги), но не может увеличивать размер физического тома.Умеет, ещё как умеет! Да и вообще понятие размера ФС у Zfs - это неясно что. Так как при создании zfs на пуле вы ни где не указываете размер самой ФС, в отличии от создания к примеру, ufs, ext* и т.д. Ах, да - ещё есть понятие резервация места, квота для Zfs - которое тоже может меняться налету. Если вы создадите 1000 ФС, то место у вас как было, так и останется неизменным (конечно оно будет меньше, так как пойдёт резервация на описание самой Zfs и её свойств, но суть останется та же)
> Умеет, ещё как умеет! Да и вообще понятие размера ФС у Zfs
> - это неясно что.Это место, которое физически занимает пул. И его нельзя увеличить без добавления новых томов.
Конечно может.
>>Поддержка расширения разделов на лету будет обеспечена для файловых систем UFS и ZFS
> А ZFS разве так не умеет?вот тоже интересно
а то небезызвестная ОС умеет довольно давно, с 2008 версиии как раз в случае виртуализации это иногда очень выручает
EXSi умеет в онлайн-режиме изменять размер дисков вроде
qemu/kvm нет, но слава богу они в оффлайне это сделали по-человечески
насчет остальных было бы интересно услыщать мнение знающих людей
>>>Поддержка расширения разделов на лету будет обеспечена для файловых систем UFS и ZFS
>> А ZFS разве так не умеет?Умеет, но afaik не на лету - нужен export/import (руками или перезагрузкой).
>>>>Поддержка расширения разделов на лету будет обеспечена для файловых систем UFS и ZFS
>>> А ZFS разве так не умеет?
> Умеет, но afaik не на лету - нужен export/import (руками или перезагрузкой).не нужно никакого export/import!!!! и тем более руками или перезагрузкой.
>>>>>Поддержка расширения разделов на лету будет обеспечена для файловых систем UFS и ZFS
>>>> А ZFS разве так не умеет?
>> Умеет, но afaik не на лету - нужен export/import (руками или перезагрузкой).
> не нужно никакого export/import!!!! и тем более руками или перезагрузкой.Как без этого ZFS узнает, что диск стал больше по размеру ? Речь про использования FreeBSD в гостевых окружениях, в которых размер виртуального диска в отличие от физического может легко меняться на лету.
>>>>Поддержка расширения разделов на лету будет обеспечена для файловых систем UFS и ZFS
>>> А ZFS разве так не умеет?
> Умеет, но afaik не на лету - нужен export/import (руками или перезагрузкой).Когда-то давно - да, был нужен export/import. Сейчас можно и без него.
>>Поддержка расширения разделов на лету будет обеспечена для файловых систем UFS и ZFS
> А ZFS разве так не умеет?Умеет. Но только в пределах наличествуемых виртуальных устройств верхнего уровня == выше головы, то бишь — количества места в VDEV, не прыгнешь — нужно добавлять к пулу ещё VDEV, а это может быть неудобно (отсутствие необходимого числа интерфейсов для включаемых носистелей, например).
Класс GEOM, который будет разработан, сможет расширить VDEV прозрачным для UFS2 и ZFS образом. То есть без добавления дополнительных устройств верхнего уровня эти файловые системы смогут расшириться на новое пространство.
Не ясно?
Попробую показать на примере. Классический путь увеличения пространства в RAID-Z из трёх дисков стостоит в последовательной замене каждого из дисков массива на диск большей ёмкости с промежуточной операцией по перестройке массива, в финале всех операций для обретения новой ёмкости ZFS пул необходимо экспортировать и снова импортировать. Такой же принцип расширения пространства, доступного ФС, но на уровне виртуальных устройств VDEV, состоящих из единичных носистелей (партиций, винчестеров без разметки и т.д.) должен обеспечить новый GEOM класс, на котором могут находиться другие уровни GEOM, UFS2, и сама ZFS.
> Но только в пределах наличествуемых виртуальных устройств верхнего уровня == выше головы, то бишь — количества места в VDEV, не прыгнешь — нужно добавлять к пулу ещё VDEV, а это может быть неудобно (отсутствие необходимого числа интерфейсов для включаемых носистелей, например).Не думал, что ZFS настолько крива и дубова, что не умеет менять размер vdev.
Итак, есть у нас например один диск на 500Гб. На нем раздел 100Гб и неразмеченная область. Строим ZFS pool на этом разделе. Сейчас использовать неразмеченную область можно двумя способоми:
- Разметить второй раздел, и добавить его в пул (это можно на ходу).
- Изменить размер первого раздела, но придётся останавливать все ФС и совершать всякие манипуляции в off-line.>Класс GEOM, который будет разработан, сможет расширить VDEV прозрачным для UFS2 и ZFS образом.
Как новый GEOM класс позволит решить проблему второго способа? Это ведь недостатки самого VDEV, что он не может использовать новое пространство нижележащего устройства (GEOM провайдера), при изменении его размера. Тут как раз понятно зачем править код ZFS.
Занятно. Для "фичастой и уберсовременной" ZFS приходится допиливать фичи, которые в XFS были сто лет в обед.
> Занятно. Для "фичастой и уберсовременной" ZFS приходится допиливать фичи, которые в XFS
> были сто лет в обед.Механизм growfs есть у UFS.
http://docs.huihoo.com/opensolaris/solaris-volume-manager-ad...
ZFS расширяется путём добавления новых VDEV. При этом все ФС в пуле разделяют одно пространство и претендуют на всё свободное место в нём.
> ZFS расширяется путём добавления новых VDEV. При этом все ФС в пуле
> разделяют одно пространство и претендуют на всё свободное место в нём.Всё верно.
А для тех, кто не верит - возьмите и сами попробуйте создать пул, создать Zfs в нём, добавить в пул новый диск и посмотреть на свободное место в zfs.