Сам по себе это не самый приятный аргумент. Я делал то же самое, в основном в процессе тестирования импорта виртуальных машин из других гипервизоров мне стало ясно, что файловая система может сэкономить время на копирование, особенно с 'огромными' дисками, которые на самом деле довольно разреженные (я так привык добавлять ТБ-диски в ВМ и потом не использовать их, полагаясь на разреженность и обрезку, чтобы они оставались маленькими). Это могло бы попасть в вашу отличную документацию (возможно, с большим количеством данных), поскольку для меня, как пользователя RHV/oVirt GlusterFS, это не так очевидно: GlusterFS не славится высокой скоростью, но если речь не идет об Infiniband, другой слой без перехода между ядром и пользовательским пространством не должен быть слишком дорогим. oVirt/RHV на самом деле накладывает еще один уровень блоков/чанков на файловую систему, но это в основном сделано для обеспечения некоторой распределенности в противном случае монолитных файлов дисков. И это также связано с тем, что oVirt/RHV изначально проектировался для SAN-хранилищ. С одной стороны, это еще одно полезное понимание, с другой стороны, 'минуты' определенно звучат катастрофически в контексте хранения. Так переводит ли помещение узла, на котором работает активный MDS, в режим обслуживания эту роль на резервный MDS без таких дорогих арбитражей? Уменьшает ли запуск резервного сервера текущий активный до резервного? (Думаю, мне стоит начать читать документацию по Ceph...) Опять же, возможно, я немного избалован тем, насколько толерантен Gluster к сбоям одного узла в хранении, но моя мотивация перейти на Proxmox и Ceph заключается в отсутствии будущего для Gluster и oVirt теперь, когда все downstream коммерческие продукты исчезли.
