Я сразу сказал что это “сферический конь” 8-) - у EMC тормоза начнутся еще те при такой загрузке 8-). Но в reserved LUN данные будут переноситься и именно он уже будет являться узким местом при росте объема, но его можно спланировать отдельно от основного. А данные реальные есть и есть изменения - т.е. база после изменений не вылазит за 1.8 Тб (но вот все шаги уже вылазят - допустим база 1 Тб и каждое изменение на диске ~250-300 Гб - последовательно таких изменений - 4 , на последнем тест и commit 8-))).

Понятно что в вышеупомянутых “файловых структурах” снапшоты достаются практически “нахаляву”. В отличии от традиционных блочных систем. Если вам кажется что это не так, предложите как в рамках блочной системы должен делаться снапшот и мы найдем для него недостатки и worst case 8-).

В WAFL мы такого не получим (да да помню про превращение random write в sequential write 8-))

Может ли объем LUN+несколько снапшотов (реальных изменений) быть размеров больше чем 1.8 Тб?

Если я правильно понял, то да - может, если LUN - thin provision.

А вообще чудес не бывает: если реальные данные ЕСТЬ - значить для них нужно место.

“Такое устройство снапшотов”.

Наверное сказывается мое “блочное” мышление 8-).

Попробую сформулировать подробнее.

Структура WAFL/ZFS/BTRFS/etc очень интересно, позволяет легко создать/управлять снапшотами. Но проблема в том, что размер изменений ограничен размерами структуры (массив дисков с WAFL) поверх которой создается структура данных.
Например:

Внутри большой системы есть массив дисков с WAFL (допустим 8 дисков по 300G - RAID-DP - грубый полезный объем 1.8 Тб)
На этом массиве есть LUN. Может ли объем LUN+несколько снапшотов (реальных изменений) быть размеров больше чем 1.8 Тб?

“Пример - Сферический конь в вакууме” - большая база (продуктив работает непрерывно) + поэтапное обновление и сохранение всех этапов для отката на любую стадию (проверка миграции на новую версию продукта)