Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 104
zfs
На мой взгляд идеальная фс, жаль только под линей+fuse дико тормозит.
На мой взгляд идеальная фс, жаль только под линей+fuse дико тормозит.
zfs способна координироваться с нижележащим блочным устройством? Как? Как выглядит процесс освобождения блоков?
что вы подразумеваете под этой витиеватой фразой?
Каким образом zfs даёт знать блочному устройству, что указанный блок можно убрать? И как это будет обрабатываться блочным устройством?
Речь именно про блочные устройства, про то, каким образом они могут взаимодействовать с файловой системой в вопросах «добавить/удалить место».
Если не понятно: вопрос о том, как с помощью файловой системы уменьшать размер VDI на диске.
Речь именно про блочные устройства, про то, каким образом они могут взаимодействовать с файловой системой в вопросах «добавить/удалить место».
Если не понятно: вопрос о том, как с помощью файловой системы уменьшать размер VDI на диске.
ну смотрите, идеология ZFS:
1) Делаем «пул» из блочных устройств по типу LVM-а
2) Поверх пула делаем «разделы», только делаются они по типу папок (никаих фоматов, фдисков и прочего — делается все моментально).
— Ты можешь сделать один раздел на весь пул.
— Можешь два и ограничить их размером в половину пула каждый.
— А можешь три, и без ограничений, и они будут занимать именно столько места, сколько данных на них есть.
Там нет нужны уменьшать\увеличивать размер раздела, можно поставить принудительно ограничение на размер конкретного раздела, чтобы он не занимал более определенного объема.
Увеличение размера пула — без проблем, уменьшение — без проблем. Но естественно, если у тебя раздел 5тб, да еще и raidz, процесс может занять неделю, но это ИМХО, проблема «универсальности» ЦП и медленная работа ЖД.
1) Делаем «пул» из блочных устройств по типу LVM-а
2) Поверх пула делаем «разделы», только делаются они по типу папок (никаих фоматов, фдисков и прочего — делается все моментально).
— Ты можешь сделать один раздел на весь пул.
— Можешь два и ограничить их размером в половину пула каждый.
— А можешь три, и без ограничений, и они будут занимать именно столько места, сколько данных на них есть.
Там нет нужны уменьшать\увеличивать размер раздела, можно поставить принудительно ограничение на размер конкретного раздела, чтобы он не занимал более определенного объема.
Увеличение размера пула — без проблем, уменьшение — без проблем. Но естественно, если у тебя раздел 5тб, да еще и raidz, процесс может занять неделю, но это ИМХО, проблема «универсальности» ЦП и медленная работа ЖД.
Смотрю. И всё ещё не понимаю, каким образом, удаляя файл на 1Тб на одной виртуальной машине, я освобождаю 1Тб для остальных виртуальных машин.
пул занимает все возможное дисковое пространство(и легко расширяем если понадобится), а для каждой виртуалки можно выделять разделы на пуле — у них обьем будет равен занятому месту данными. Записали в раздел еще данных — он увеличился за счет свободного места из пула, удалили данные — раздел уменьшился и отдал пустое пространство в пул где его может использовать раздел любой другой виртуалки. Както так)
Раздел уменьшился? Как он понял, что нужно уменьшаться? Через какое API это делается?
это не через апи делается) это делает сама фс — она так устроена. Все физически доступное место является пулом, а все разделы внутри него занимают места ровно столько сколько в них данных. Данных добавили раздел увеличился за счет свободного места в пуле, данные удалили — свободное место опять отдается в пул на пользование другим разделам.
Ага. Уже интересно. Теперь вопрос: как обеспечить сосуществование двух и более VM на одном блочном устройстве?
вот тут уже точно не скажу, надо пробовать на практике. если с обычными фс там все просто — при форматировании появляется новое вирт блочное устройство, то тут я не уверен ведут ли разделы себя также. Хотя мне кажется это уже проблема системы виртуализации, а не фс — выдать каждой VM определенный раздел. А квоты(макс обьем раздела до которого позволено разростатся) можно уже и средствами фс ставить.
Можно попробовать расшарить раздел (ну т.е. файловую систему zfs) через iscsi. И вообще по хорошему вы пытаетесь изобрести велосипед — уже давно оформилось разделение между серверами и стораджами. Советую вам посмотреть на последние достичения в области storage и подключения по iscsi через гигабит или FB.
RAID-Z на этом построен.
Ну, и для reiser4 (он, кстати, reiser, а не raiser) можно сделать плагин.
Reiserfs умеет динамическое увеличение без остановки.
Ну, и для reiser4 (он, кстати, reiser, а не raiser) можно сделать плагин.
Reiserfs умеет динамическое увеличение без остановки.
недавно проскакивала новость что уже написали модуль ядра для zfs, скоро про fuse можно будет забыть
ZFS + Solaris. Доступны любые представимые действия с файловой системой.
Линукс же в настоящее время работает с ZFS только через костыли.
Линукс же в настоящее время работает с ZFS только через костыли.
Да не подходит ZFS. ZFS отлично (в этой части) эмулируется с помощью LVM + обычная FS, но это явно не автоматическое on-demand выделение и освобождение места. Кроме того, совершенно не ясно, как именно ZFS может пережить изменение диска (1шт) с 10Гб до 5Гб.
>>>изменение диска (1шт) с 10Гб до 5Гб
Легко. Добавляем в пул диск в 5 гигов, удаляем 10 гиговый, это при условии что не используется RAIDZ\Stripe и данных в пуле меньше 5 гигов.
Легко. Добавляем в пул диск в 5 гигов, удаляем 10 гиговый, это при условии что не используется RAIDZ\Stripe и данных в пуле меньше 5 гигов.
zfs autoexpand — почему нет?
Мне очень интересна эта тема. Если пропущу путный ответ — пожалуйста, напиши в хабрапочту.
Мы думали, думали… и так и не нашли «дешевого» в плане разработки и внедрения решения (Xen). С CIFS/SMB все хорошо. С блочными устройствами — плохо. как минимум — прийдется его отмонтировать и ресайзнуть неким управляющим скриптом, потом примонтировать в гостевой OS.
Мы думали, думали… и так и не нашли «дешевого» в плане разработки и внедрения решения (Xen). С CIFS/SMB все хорошо. С блочными устройствами — плохо. как минимум — прийдется его отмонтировать и ресайзнуть неким управляющим скриптом, потом примонтировать в гостевой OS.
Есть виртуальная инфраструктура VMware ESX 3.5 + vSphere. Регулярно меняю размер системных разделов на работающих виртуальных серверах 2003, 2008 и 2008 R2. Для расширения системного диска внутри виртуалки с 2003 виндой требуется утилита от Dell под названием ExtPart. Увеличение размера происходит прямо в онлайне, без остановки виртуальной машины. В винде же 2008 и старше увеличение размера осуществляется штатными средствами, через оснастку «управление дисками», в 2 клика, опять же без остановки.
Да, весь увеличенный объем можно использовать сразу же, никакого многочасового ожидания.
Как говорится, enlarge and enjoy :)
Да, весь увеличенный объем можно использовать сразу же, никакого многочасового ожидания.
Как говорится, enlarge and enjoy :)
Да и с уменьшением (shrink) на лету системных разделов под NTFS в Windows Server 2008 и выше стандартными утилитами проблем никаких нет.
А это уже, на мой взгляд, должно быть проблемой совсем не файловой системы, а СХД, и, кстати, у многих вендоров Thin Provisioning реализован и вполне успешно работает.
Файловая система должна быть минимально возможного размера. Если у нас занято 2Гб, то размер файловой системы 2Гб + служебные данные.
А это уже, на мой взгляд, должно быть проблемой совсем не файловой системы, а СХД, и, кстати, у многих вендоров Thin Provisioning реализован и вполне успешно работает.
вы это делаете руками или из скриптов. Я же говорю про ситуацию, когда у вас кто-то начинает писать файл в 1Тб на системный диск в 2Гб размером… И успешно записывает, потому что файловая система запросила 1Тб у блочного устройства, блочное устройство увеличилось в размере, файловая система увеличилась в размере…
После того, как файл стёрли, всё прошло обратно. Без каких-то ручных телодвижений.
После того, как файл стёрли, всё прошло обратно. Без каких-то ручных телодвижений.
Изначально вопрос звучал так:
Большинство систем виртуализации позволяет изменять размер дисков. Многие системы позволяют это делать на ходу, в онлайне.Если приходится писать терабайтные файлы на системный раздел, значит, инфраструктура спроектирована отвратительно. Под подобные задачи нужен отдельный сторедж, специально рассчитанный на работу с громадными объемами данных. Облако хранения, или High-End хранилище с собственной логикой.
Вопрос звучит так: а может ли гостевая ОС воспользоваться этим местом свободно? Этот вопрос выходит за рамки виртуализации и является общим вопросом: есть ли у нас файловые системы, которые способны динамически изменяться в размере в штатном режиме?
А если мы уже про облако говорим? И «системный раздел» лишь условность, оно всё лежит на сетевом сторе?
Если мы уже говорим про облако, то у нас нет задачи менять системный раздел. Логика у нас живет в ПЗУ, либо в специально отведенной флешке (или на отдельном диске/массиве).
Из сравнительно простого, что приходилось щупать руками — сторедж с ZFS. Имеется, к примеру, 10 терабайтных дисков в одном ZFS пуле. Внутри этого пула создаются разделы — сколько угодно — которые шарятся любым способом — NFS, CIFS, iSCSI, FC. Если не ограничивать размер раздела, он может занять всё свободное на пуле место, все 10 условных терабайт. Файлы удаляются — место освобождается, и всё это в автоматическом режиме без участия админа. Можно добавлять/удалять физические диски (hot-spare, разумеется), при этом размер пула соответственно изменяется.
В общем, я не нахожу резона усложнять то, что мы условно называем системным разделом. Лишняя гибкость может выйти боком. Винда даже запрещает обычным юзерам запись на системный раздел. Вот дополнительный сторедж можно колбасить по полной, да.
P.S. Как-то мы лихо уехали от виртуалок в облака…
Из сравнительно простого, что приходилось щупать руками — сторедж с ZFS. Имеется, к примеру, 10 терабайтных дисков в одном ZFS пуле. Внутри этого пула создаются разделы — сколько угодно — которые шарятся любым способом — NFS, CIFS, iSCSI, FC. Если не ограничивать размер раздела, он может занять всё свободное на пуле место, все 10 условных терабайт. Файлы удаляются — место освобождается, и всё это в автоматическом режиме без участия админа. Можно добавлять/удалять физические диски (hot-spare, разумеется), при этом размер пула соответственно изменяется.
В общем, я не нахожу резона усложнять то, что мы условно называем системным разделом. Лишняя гибкость может выйти боком. Винда даже запрещает обычным юзерам запись на системный раздел. Вот дополнительный сторедж можно колбасить по полной, да.
P.S. Как-то мы лихо уехали от виртуалок в облака…
Тыг, повторю ещё раз: облака — это метод учёта ресурсов. В частности, для виртуалки. И чтобы виртуалка стала облачной, ей нужно дать места «жри сколько хочешь, заплатишь за сожранное».
Ну так и не надо здесь локальных файловых систем, пусть виртуалка по NFS/CIFS до стореджа доступается. Папка /docs или сетевой диск. А сторедж on-demand сам разрулит, кому сколько выделить. Зачем усложнять локальную файловую систему, если уже есть решения, заточенные под гибкое хранение?
Ага. Теперь следующий вопрос: как бы это совместить с необходимостью грузить систему?
Я уже думал о «бездисковой виртуальной машине», которая бы с NFS грузилась бы, но как-то это очень громоздко выглядит…
Я уже думал о «бездисковой виртуальной машине», которая бы с NFS грузилась бы, но как-то это очень громоздко выглядит…
Здесь есть проблема с безопасностью доступа. Пока мы имеет storage network и опосредованный доступ через платформу виртуализации, нет опасности прослышивания трафика.
Как только подключим сторадж прямо в виртуалку, например Microsoft iSCSI Initiator, скажем «до свидания» безопасности.
Как только подключим сторадж прямо в виртуалку, например Microsoft iSCSI Initiator, скажем «до свидания» безопасности.
Ну, для этого и существует nfsv4 с керберосом. А там уже на выбор krb5, krb5i, krb5p.
Алсо, слушать трафик на виртуалке никто не даст, виртуальный интерфейс воткнут в виртуальный коммутатор, который прекрасно заметит хулиганство со стороны VM. (а в принципе, его можно вообще запретить как класс).
Алсо, слушать трафик на виртуалке никто не даст, виртуальный интерфейс воткнут в виртуальный коммутатор, который прекрасно заметит хулиганство со стороны VM. (а в принципе, его можно вообще запретить как класс).
Виртуальный коммутатор воткнут в физический коммутатор.
И? Трафик-то фильтруется на вируальном коммутаторе. Не пройдя его дорваться до вышестоящих коммутаторов не получится. А фильтр «не флудить маками» на самом деле очень легко пишется (по-крайней мерере в Open vSwitch, который в Xen Cloud Platform идёт).
iSCSI трафик уходит с виртуального коммутатора на физический и так до iSCSI target. Вот как только он ушел в физическую сеть, его можно слушать, поскольку он ушел не в выделенный сегмент для iSCSI а через general purpose.
Простите, КТО будет слушать трафик в сети между хостом/iscsi target? Гостевые VM? Я написал выше.
Тот, кто подключен к тому же физическому коммутатору.
К фическому коммутатору подключен шлюз, хосты виртуализации, сторедж, виртуальные коммутаторы внутри хост.
В случае использования Software iSCSI из гостевой ОС идет чистый нешифрованный трафик:
гостевая ОС -> виртуальный коммутатор -> физический коммутатор ->… -> физический коммутатор -> iSCSI Target
причем он идет на физический коммутатор по тому же линку, что и обычный трафик виртуальных машин, с теми же настройками безопасности. Прослушать iSCSI трафик = украсть диск можно на любой физической точке от хоста до таргета.
Если же iSCSI используется (на примере VMware) для создания VMFS датастора, то по всем рекомендациями и руководствам iSCSI сеть ввиду ее незащищенности должна быть отделена физически или как минимум в отдельный VLAN. Трафик iSCSI не встречается с general purpose трафиком, к которому имеет доступ кто угодно и может подключиться откуда угодно.
гостевая ОС -> виртуальный коммутатор -> физический коммутатор ->… -> физический коммутатор -> iSCSI Target
причем он идет на физический коммутатор по тому же линку, что и обычный трафик виртуальных машин, с теми же настройками безопасности. Прослушать iSCSI трафик = украсть диск можно на любой физической точке от хоста до таргета.
Если же iSCSI используется (на примере VMware) для создания VMFS датастора, то по всем рекомендациями и руководствам iSCSI сеть ввиду ее незащищенности должна быть отделена физически или как минимум в отдельный VLAN. Трафик iSCSI не встречается с general purpose трафиком, к которому имеет доступ кто угодно и может подключиться откуда угодно.
Системный раздел не условность, если речь идет о винде.
1) если по какой-то причине надо переустановить ОС, то можно не беспокоиться о сохранности данных — он будут лежать не на системном разделе
2) виртуальный диск с ОС может лежать на low-end storage, ведь по сути надо только заугрзиться. А данные на сверхможном дорогом массиве
1) если по какой-то причине надо переустановить ОС, то можно не беспокоиться о сохранности данных — он будут лежать не на системном разделе
2) виртуальный диск с ОС может лежать на low-end storage, ведь по сути надо только заугрзиться. А данные на сверхможном дорогом массиве
> Windows тут выглядит полным ауткастером, так как не поддерживает изменение размера файловой системы NTFS, особенно, на системных дисках.
либо «не поддерживает» (вообще не поддерживает), либо «особенно, на системных дисках» (поддерживает, но есть известные проблемы)
и вообще пи… дёжь и провокация: ещё в 2k были реализованы динамические диски и тома
А разве высокая степерь виртуализации не подразумевает максимальное абстрагирование от аппаратной части. Я к тому, что при таких задачах (облако) наверное надо не блочные устройства эмулировать, а по максимуму использовать файловый доступ (NFS/SMB).
либо «не поддерживает» (вообще не поддерживает), либо «особенно, на системных дисках» (поддерживает, но есть известные проблемы)
и вообще пи… дёжь и провокация: ещё в 2k были реализованы динамические диски и тома
А разве высокая степерь виртуализации не подразумевает максимальное абстрагирование от аппаратной части. Я к тому, что при таких задачах (облако) наверное надо не блочные устройства эмулировать, а по максимуму использовать файловый доступ (NFS/SMB).
NFS/SMB — бесконечно медленно, по сравнению со скоростью операций с блочными устройствами.
Насчёт SMB не скажу, но в сравнении NFS/iSCSI я не заметил существенных различий.
Динамические тома-то она поддерживает. А изменение размера системного диска? Не затруднит ткнуть в команду в 2003/2008 для этого?
Ну, этот вариант я тоже прорабатываю. Проблема в том, что в отличие от блочного устройства, на NFS очень сложно учитывать число дисковых операций.
Btrfs начиная с 2.6.35 не будет иметь статус экспериментальной ФС.
Про увеличение/уменьшение здесь: btrfs.wiki.kernel.org/index.php/Btrfsctl
Но только вручную.
Про увеличение/уменьшение здесь: btrfs.wiki.kernel.org/index.php/Btrfsctl
Но только вручную.
Проблема далеко не новая, и для нее уже давно есть решение.
Thin Provisioning
Thin Provisioning
А, в комментарии выше уже упомянули, не заметил.
Спасибо. Прочитал. Издалека выглядит как то, что нужно, но совсем не ясно, с помощью чего это делать.
Мне бы в более техничных терминах. Кто-то создаёт файл большого размера (в локальной FS, для драматизма, допустим, что прямо в '/'). Этот запрос: (вот тут бы мне вписать нужное)…
Разбирался с этой штукой года полтора назад, поэтому возможно что-то забыл, пусть комментаторы меня поправят.
Выглядит это так — есть у вас некая СХД (EMC, Hitachi, NetApp, Infortrend — у них у всех это есть). Есть у вас, некая рейд-группа на имеющихся дисках, пусть полезный объем будет 15 Тб. вы берете, и с помощью Thin Provisioning создаете 30 лунов по 1 Тб (условно) и мапите их к вашим виртуальным серверам или вообще куда угодно. Соответственно ваши сервера видят свои блочные устройства по 1 Тб и вообще понятия не имеют, что там на массиве при этом творится. Вся головная боль по распределению и хранению данных ложится на СХД. Если при этом в процессе работы у вас начинает заканчиваться место — вы докупаете еще диски и дисковые полки, расширяете рейд-группу и т.д.
Вся прелесть такого подхода раскрывается в связке с дедупликацией, когда при наличии множества одинаковых виртуалок, реально на СХД занято очень-очень мало места.
Вот как-то так.
Выглядит это так — есть у вас некая СХД (EMC, Hitachi, NetApp, Infortrend — у них у всех это есть). Есть у вас, некая рейд-группа на имеющихся дисках, пусть полезный объем будет 15 Тб. вы берете, и с помощью Thin Provisioning создаете 30 лунов по 1 Тб (условно) и мапите их к вашим виртуальным серверам или вообще куда угодно. Соответственно ваши сервера видят свои блочные устройства по 1 Тб и вообще понятия не имеют, что там на массиве при этом творится. Вся головная боль по распределению и хранению данных ложится на СХД. Если при этом в процессе работы у вас начинает заканчиваться место — вы докупаете еще диски и дисковые полки, расширяете рейд-группу и т.д.
Вся прелесть такого подхода раскрывается в связке с дедупликацией, когда при наличии множества одинаковых виртуалок, реально на СХД занято очень-очень мало места.
Вот как-то так.
>Вся прелесть такого подхода раскрывается в связке с дедупликацией
В случае интенсивной работы виртуалок с дисковой системой, когда кладутся и удаляются большие файлы, необходимо предусмотреть регулярное обнуление свободного пространства, чтобы онво дедуплицировалось и диски на СХД освободились для новых данных.
В случае интенсивной работы виртуалок с дисковой системой, когда кладутся и удаляются большие файлы, необходимо предусмотреть регулярное обнуление свободного пространства, чтобы онво дедуплицировалось и диски на СХД освободились для новых данных.
wafl?
Veritas File System + Veritas Volume Manager.
Изменение размера образа диска по состоянию файловой системы виртуальной машины — прерогатива гипервизора. В качестве виртуального диска выделяется определенный файл, но менять его размер гостевая система не сможет, только гипервизор. То есть подобную функциональность стоит требовать от системы виртуализации, а не от файловой системы.
Думаю, можно создать 10 Тб сжатых нулей и использовать гипервизором в качестве диска, а в гостевой системе удалять данные с заполнением нулями.
Думаю, можно создать 10 Тб сжатых нулей и использовать гипервизором в качестве диска, а в гостевой системе удалять данные с заполнением нулями.
По-моему автор немного смешал 2 понятия: из ОС у нас может быть доступ на уровне ФС и на уровне блочного устройства.
Блочное устройство позволяет гораздо больше, например довесить к некоторым типам ФС модули вроде квот, либо вообще сменить ФС, или совсем уж без ФС работать (tar на раздел к примеру или свап), а на ФС — теоретической возможности unerase пока еще неперезаписанных данных. Эти дополнительные возможности САМИ ПО СЕБЕ исключают возможность создания метаинформации о занятости/незанятости определенного места на блочном устройстве.
Однако чаще всего в типовых виртуалках (VPS/VDS) эти возможности не очень-то и нужны, и вполне достаточно было бы NFS/SMB-like (только с более упрощенным интерфейсом на хост-систему, чтобы не было оверхеда на сетевой стек) файловой системы с чуть более расширенными возможностями, вроде опять же, соответствующих ОС системе прав доступа, квот на иерархию (к примеру чтобы /var не занял все место, что сейчас реализуется размером раздела отчасти)… В принципе что-то вроде этого и реализовано в OpenVZ например, но это конечно же сугубо частное решение в плане ОСозависимости ;)
В общем, для решения проблемы ИМХО надо думать в сторону отказа от излишней промежуточной эмуляции блочного устройства.
Блочное устройство позволяет гораздо больше, например довесить к некоторым типам ФС модули вроде квот, либо вообще сменить ФС, или совсем уж без ФС работать (tar на раздел к примеру или свап), а на ФС — теоретической возможности unerase пока еще неперезаписанных данных. Эти дополнительные возможности САМИ ПО СЕБЕ исключают возможность создания метаинформации о занятости/незанятости определенного места на блочном устройстве.
Однако чаще всего в типовых виртуалках (VPS/VDS) эти возможности не очень-то и нужны, и вполне достаточно было бы NFS/SMB-like (только с более упрощенным интерфейсом на хост-систему, чтобы не было оверхеда на сетевой стек) файловой системы с чуть более расширенными возможностями, вроде опять же, соответствующих ОС системе прав доступа, квот на иерархию (к примеру чтобы /var не занял все место, что сейчас реализуется размером раздела отчасти)… В принципе что-то вроде этого и реализовано в OpenVZ например, но это конечно же сугубо частное решение в плане ОСозависимости ;)
В общем, для решения проблемы ИМХО надо думать в сторону отказа от излишней промежуточной эмуляции блочного устройства.
так а nfs поддерживает упомянутые операции?
Да, только несколько в иной форме. NFS предполагается «общей» для разных VM: как только один гость удаляет файл, место сразу же доступно для других гостей для записи.
ну так её же можно реализовать через «паравиртуальный сетевой интерфейс»,
(paravirtualized network adapter), чтобы избавиться от расходов на лишнюю виртуализацию.
и будет всем счастие, наверно.
(paravirtualized network adapter), чтобы избавиться от расходов на лишнюю виртуализацию.
и будет всем счастие, наверно.
да, есть такое решение. Проблема только в учёте дисковых операций…
а какие проблемы с учётом операций?
вроде бы в NFSv4 есть учёт операций и даже квоты.
а хотя какой нафик виртуальный сетевой интерфейс.
я ч-то-то туплю.
оно же через rpc работает. а их можно завернуть хоть через локальные сокеты, хоть через чёрталысого, специально адаптированного.
непонятно только, насколько существенны получатся расходы на rpc.
я ч-то-то туплю.
оно же через rpc работает. а их можно завернуть хоть через локальные сокеты, хоть через чёрталысого, специально адаптированного.
непонятно только, насколько существенны получатся расходы на rpc.
Ну, тут изобретать-то особо нечего: виртуальный сетевой адаптер, разворачивающийся в отдельный вилан. Вопрос только в одном: как это считать…
А можно спросить, какую практическую задачу вы хотите решить? Если я правильно понял по комментариям, все это про облачные хостинги. Тогда какие нужные преимущества для клиентов (или с точки зрения себестоимости?) такой online-resize даст? Может быть, есть другие способы этого добиться. Или не добиваться.
>Сторонние утилиты умеют это делать, но не на ходу…
Dell ExtPart (36кБ, бесплатная) умеет увеличивать размер системного раздела «на ходу»
Dell ExtPart (36кБ, бесплатная) умеет увеличивать размер системного раздела «на ходу»
Кстати, а AFS разве этого не умеет?
за исключением системного раздела в винде можно и увеличивать и уменьшать разделы
вполне очевидно что это долго — ведь надо все файлы с освобождаемого места убрать
почему вы удивляетесь?
а на линуксе обычно сотни миллионов файлов, вот и 12 часов вам…
вполне очевидно что это долго — ведь надо все файлы с освобождаемого места убрать
почему вы удивляетесь?
а на линуксе обычно сотни миллионов файлов, вот и 12 часов вам…
Трэд не читал но скажу. Полностью правильное решение должно включать в себя и файловую систему в госте — туда должен прокидываться не блок-девайс а блок-аллокатор. Такого похоже ещё нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблема динамического выделения дискового пространства виртуальных машин