>>> Если Вы считаете, что ploop - простой, то я бы хотел увидеть его портинг в апстрим, это именно то, что сейчас нужно очень многим.
>> Сколько пива выставите ?:) он реально простой - это же блочное устройство
>> - а не FS.
>> Портирование можно сделать за неделю - было бы желание и свободное время.
> А как быть с юзерспейсом ploop? Юзер спейс ploop - это только монтирование/вытаскивание образа. что такое ext4 и вообще любая другая FS - ploop не знает. Еще раз подчеркну ploop это только блочное устройство.
> vzctl compact научить сжимать ext4 в
> случае развесистой метадаты - еще то развлечение, || эту фичу
> уже год обещает и постоянно откладывает :/
Учитывая кучу комитов от паралелс в ext4 для resize - можно предположить что это сделано на базе этой фичи.
И она весьма не стабильна сейчас. Что в очередной раз поднимает вопрос о стабильности ext4. Родившейся из вполне понятного набора патчей одной конторы.
> Да и когда речь
> идет про все связанное с хранением - надо иметь полные покрывающие
> тесты. У || они есть, а у нас, увы, нету, что
> приводит к тому, что их надо написать и досконально понимать что
> и когда может произойти.
Зная как идет разработка внутри parallels - могу сказать что врядли у них есть тесты. Так же могу назвать стопку проблем с OpenVZ которые не исправлены и существуют by design. Для затравки предложу подумать что будет если попытаться ограничить запись журнала в рамках iolimit. или что делать в случае NFS клиента (как известно сделаного в виде FSM) когда один или несколько процессов влетают в hard cpu limit. Можно еще вспомнить :)
> Кроме этого, из сложностей ploop - собственный фреймворк для записи данных на
> диск в обход page cache - это еще то развлечение, можете
> полистать код, там много и забористо.
Так просто как 2 копейки :-) полистайте код http://git.whamcloud.com/fs/lustre-release.git - там более не тривиальные вещи.
