1.1, manefesto (??), 11:43, 07/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
очень круто.
пока правда не знаю где применить, но вполне неплохой задел если на одном из разделов кончилось место
| |
|
2.3, Аноним (-), 11:59, 07/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> очень круто.
> пока правда не знаю где применить, но вполне неплохой задел если на
> одном из разделов кончилось место
В виртуальных окружениях место можно увеличивать сколько угодно.
| |
|
|
2.28, Mna (??), 10:48, 08/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
Хотелось бы уменьшения *хотя бы* для не примонтированной FS UFS
| |
|
1.5, xxx (??), 12:24, 07/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>Поддержка расширения разделов на лету будет обеспечена для файловых систем UFS и ZFS
А ZFS разве так не умеет?
| |
|
2.6, skeletor (ok), 12:28, 07/03/2012 [^] [^^] [^^^] [ответить]
| –4 +/– |
>>Поддержка расширения разделов на лету будет обеспечена для файловых систем UFS и ZFS
> А ZFS разве так не умеет?
Умеет. Неясно что они этим хотели сказать.
| |
|
|
4.16, Аноним (-), 18:54, 07/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Может не они, а горе-переводчик новости.
В оригинал заглянуть слабо ?
"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 не узнает, что диск стал больше, хоть он уже и умеет расширение без отмонтирования.
| |
|
3.10, Аноним (-), 15:45, 07/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Умеет. Неясно что они этим хотели сказать.
Afaik, ZFS умеет только менять размеры "подсистем" (т.е., фактически, квоты на отдельные каталоги), но не может увеличивать размер физического тома.
| |
|
4.11, skeletor (ok), 16:06, 07/03/2012 [^] [^^] [^^^] [ответить]
| –3 +/– |
>> Умеет. Неясно что они этим хотели сказать.
> Afaik, ZFS умеет только менять размеры "подсистем" (т.е., фактически, квоты на отдельные
> каталоги), но не может увеличивать размер физического тома.
Умеет, ещё как умеет! Да и вообще понятие размера ФС у Zfs - это неясно что. Так как при создании zfs на пуле вы ни где не указываете размер самой ФС, в отличии от создания к примеру, ufs, ext* и т.д. Ах, да - ещё есть понятие резервация места, квота для Zfs - которое тоже может меняться налету. Если вы создадите 1000 ФС, то место у вас как было, так и останется неизменным (конечно оно будет меньше, так как пойдёт резервация на описание самой Zfs и её свойств, но суть останется та же)
| |
|
5.20, Аноним (-), 21:34, 07/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Умеет, ещё как умеет! Да и вообще понятие размера ФС у Zfs
> - это неясно что.
Это место, которое физически занимает пул. И его нельзя увеличить без добавления новых томов.
| |
|
|
|
2.8, rico (ok), 13:16, 07/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>>Поддержка расширения разделов на лету будет обеспечена для файловых систем UFS и ZFS
> А ZFS разве так не умеет?
вот тоже интересно
а то небезызвестная ОС умеет довольно давно, с 2008 версии
и как раз в случае виртуализации это иногда очень выручает
EXSi умеет в онлайн-режиме изменять размер дисков вроде
qemu/kvm нет, но слава богу они в оффлайне это сделали по-человечески
насчет остальных было бы интересно услыщать мнение знающих людей
| |
|
3.13, Аноним (-), 16:25, 07/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>>>Поддержка расширения разделов на лету будет обеспечена для файловых систем UFS и ZFS
>> А ZFS разве так не умеет?
Умеет, но afaik не на лету - нужен export/import (руками или перезагрузкой).
| |
|
4.15, skeletor (ok), 18:41, 07/03/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
>>>>Поддержка расширения разделов на лету будет обеспечена для файловых систем UFS и ZFS
>>> А ZFS разве так не умеет?
> Умеет, но afaik не на лету - нужен export/import (руками или перезагрузкой).
не нужно никакого export/import!!!! и тем более руками или перезагрузкой.
| |
|
5.17, Аноним (-), 18:59, 07/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>>>>>Поддержка расширения разделов на лету будет обеспечена для файловых систем UFS и ZFS
>>>> А ZFS разве так не умеет?
>> Умеет, но afaik не на лету - нужен export/import (руками или перезагрузкой).
> не нужно никакого export/import!!!! и тем более руками или перезагрузкой.
Как без этого ZFS узнает, что диск стал больше по размеру ? Речь про использования FreeBSD в гостевых окружениях, в которых размер виртуального диска в отличие от физического может легко меняться на лету.
| |
|
4.32, Anon Y Mous (?), 19:50, 11/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>>>>Поддержка расширения разделов на лету будет обеспечена для файловых систем UFS и ZFS
>>> А ZFS разве так не умеет?
> Умеет, но afaik не на лету - нужен export/import (руками или перезагрузкой).
Когда-то давно - да, был нужен export/import. Сейчас можно и без него.
| |
|
|
2.18, iZEN (ok), 21:02, 07/03/2012 [^] [^^] [^^^] [ответить]
| +3 +/– |
>>Поддержка расширения разделов на лету будет обеспечена для файловых систем UFS и ZFS
> А ZFS разве так не умеет?
Умеет. Но только в пределах наличествуемых виртуальных устройств верхнего уровня == выше головы, то бишь — количества места в VDEV, не прыгнешь — нужно добавлять к пулу ещё VDEV, а это может быть неудобно (отсутствие необходимого числа интерфейсов для включаемых носистелей, например).
Класс GEOM, который будет разработан, сможет расширить VDEV прозрачным для UFS2 и ZFS образом. То есть без добавления дополнительных устройств верхнего уровня эти файловые системы смогут расшириться на новое пространство.
Не ясно?
Попробую показать на примере. Классический путь увеличения пространства в RAID-Z из трёх дисков стостоит в последовательной замене каждого из дисков массива на диск большей ёмкости с промежуточной операцией по перестройке массива, в финале всех операций для обретения новой ёмкости ZFS пул необходимо экспортировать и снова импортировать. Такой же принцип расширения пространства, доступного ФС, но на уровне виртуальных устройств VDEV, состоящих из единичных носистелей (партиций, винчестеров без разметки и т.д.) должен обеспечить новый GEOM класс, на котором могут находиться другие уровни GEOM, UFS2, и сама ZFS.
| |
|
3.22, Аноним (-), 21:44, 07/03/2012 [^] [^^] [^^^] [ответить]
| –3 +/– |
> Но только в пределах наличествуемых виртуальных устройств верхнего уровня == выше головы, то бишь — количества места в VDEV, не прыгнешь — нужно добавлять к пулу ещё VDEV, а это может быть неудобно (отсутствие необходимого числа интерфейсов для включаемых носистелей, например).
Не думал, что ZFS настолько крива и дубова, что не умеет менять размер vdev.
| |
3.30, xxx (??), 14:22, 08/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
Итак, есть у нас например один диск на 500Гб. На нем раздел 100Гб и неразмеченная область. Строим ZFS pool на этом разделе. Сейчас использовать неразмеченную область можно двумя способоми:
- Разметить второй раздел, и добавить его в пул (это можно на ходу).
- Изменить размер первого раздела, но придётся останавливать все ФС и совершать всякие манипуляции в off-line.
>Класс GEOM, который будет разработан, сможет расширить VDEV прозрачным для UFS2 и ZFS образом.
Как новый GEOM класс позволит решить проблему второго способа? Это ведь недостатки самого VDEV, что он не может использовать новое пространство нижележащего устройства (GEOM провайдера), при изменении его размера. Тут как раз понятно зачем править код ZFS.
| |
|
|
1.21, Аноним (-), 21:36, 07/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Занятно. Для "фичастой и уберсовременной" ZFS приходится допиливать фичи, которые в XFS были сто лет в обед.
| |
|
|
3.33, skeletor (ok), 18:43, 12/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> ZFS расширяется путём добавления новых VDEV. При этом все ФС в пуле
> разделяют одно пространство и претендуют на всё свободное место в нём.
Всё верно.
А для тех, кто не верит - возьмите и сами попробуйте создать пул, создать Zfs в нём, добавить в пул новый диск и посмотреть на свободное место в zfs.
| |
|
|
|