Это различие не имеет значения для PVE или любой другой платформы виртуализации, которая не использует файлы для хранения, как уже писал @aaron. Я ВСЕГДА рекомендую запускать trim/discard внутри гостевой системы, чтобы действительно освободить фактически свободное пространство. Это не слишком известно, потому что VMware не особо поддерживает это для VMDK-файлов и, по крайней мере на момент моего последнего теста, требуется время простоя для сжатия файла. Файлы — это беда для ВМ: много потенциала по производительности и экономии места просто теряется на файловых системах. Даже LVM-thin и RBD не такие уж суперспециалисты по thin provisioning, у них слишком большие единицы выделения, которые требуют дальнейшей оптимизации. Размеры единиц выделения измеряются в мегабайтах, а не в 8КБ или 16КБ, как в зависимости от поколения PVE в ZFS. Мы смотрим только на использование пространства на верхнем уровне, не учитывая бэкенд с репликацией, копированием, RAID и т.д. Если записан всего один бит (всё остальное нули), вы тем не менее всегда записываете целую единицу выделения — мегабайты в LVM-thin, мегабайты в RBD без сжатия, может меньше в RBD с сжатием и в ZFS всегда размер volblocksize (меньше со сжатием). Это плохо для экономии места. Фрагментация файловой системы тоже влияет, поэтому диск всегда нужно дефрагментировать. Много разбросанных блоков размером 4К гостевой ОС на разных огромных единицах по 2 Мб — это проблема и мешает оптимальному thin provision. Дефрагментация не так проста, как кажется, потому что большинство ВМ эмулируют SSD (оптимизируют планировщик ввода-вывода так, чтобы не оптимизировать очередь диска), и, например, Windows распознает SSD и вообще не дефрагментирует его. Это логично для настоящих SSD, но не для сложных систем хранения с thin provisioning в виртуализации. В типичных системах хранения часто встречаются блоки по 128К, что лучше мегабайтных, но всё равно хуже, чем 8K/16K. Кстати, большие единицы выделения не всегда плохи — у них есть преимущество в гораздо лучшей степени сжатия, потому что сжимать большие файлы проще, чем маленькие. Это также влияет на использование пространства на стороне бэкенда, хотя, по моему мнению, LVM-thin по умолчанию сжатие не включает. RBD тоже не сжимает по умолчанию, но сжатие можно легко включить. В ZFS сжатие включено по умолчанию, но при ashift 12 заметного сжатия почти нет. Если повезет и вы ещё на нативном блоке 512 и ashift 8, сжатие будет намного лучше. Эта тема — большая бездонная яма. Есть один способ оптимизировать фактическое использование места на диске. Если регулярно делать такие оптимизации, можно здорово сэкономить пространство в thin provisioned окружении, но при этом вы будете сильнее загружать бэкенд-бэкапы — потому что дефрагментированный диск обычно хуже поддается дедупликации, так как блоки изменились. Так что это может вам потом аукнуться.