Так тонко, что даже тонко

Нет, для этого есть юз-кейс - приоритизация. У вас работает три системы: одна - фронтенд, другая - обработка финансовых транзакций, третья - постоянное дообучение систем машинного обучения на основе новых данных для подсказок пользователям. Если отвалятся первые две, то это катастрофа. Если отвалится вторая, даже на три дня - никто (из пользователей) не заметит.

График общего потребления ресурсов показывает что 80% времени суммарное потребление диска не превышает X. Вы можете выделить приблизительно X и тогда 20% времени система машинного обучения не будет работать, так как модель она сохранить то сможет, но временного пространства диска будет не хватать. Но и хрен с ней, все согласны.

А кем, собственно, считается ?

Потому что производительность страдает. Особенно когда начинаются фокусы с бекапами, клонированием, снапшотами, суспендами и т.п. При повседневной работе пофиг.

Тонкий диск, надо постоянно расширять, если конечно он не r/o. Расширение это довольно дорогая операция на метадате, плюс некоторое количество лишних IO.

Если тонкий диск очень быстро растет (быстрый диск и множество записей), то он может тупо не успевать расширяться вовремя, особенно если шаг увеличения настроен на небольшой размер. В qcow2 например, по умолчанию этот шаг - 4k, что конечно хорошо для экономии места, но полный идиотизм в продакшене (oVirt/RHEV увеличивают его сразу до 512Mb например, чтоб сэкономить на операциях метадаты)

Тонкий диск сам по себе не сжимается, это надо делать вручную. Стирая файлы внутри VM, диск меньше не станет. Более того, скорее всего новые записи будут направлены на новые блоки, а не очищенные от файлов, что опять же заставит тонкий диск расширяться, а дальше - см. выше

Ну и последнее. Если набить физически доступное место тонкими дисками а потом начать работать с этими дисками, можно упереться в нехватку места, что остановит виртуальные машины, поенциально на всем сервере или кластере использющем общий LUN

Thin provisioning это такая маркетологическая подстановка для более честного термина overselling. Только overselling обычно говорят когда продано другим за деньги, а когда самому себе - то говорят так как о чем ты спрашивал.

Оно может породить overcommitting.

Расширение это довольно дорогая операция на метадате, плюс некоторое количество лишних IO.

Поэтому для метаданных используют отдельное устройство на SSD.

Тонкий диск сам по себе не сжимается, это надо делать вручную.

4.2 Thin LVM корректно обрабатывает trim/discard и возвращает блоки обратно в общий пул.

Класс. Только вот диски виртуалок обычно не thin LV проброшенный прямо в VM, a файл, и метаданные дисков упакованы в файл самого диска. Как мне разнести метадату qcow2 по разным дискам? И какое отношение ThinLVM имеет к qcow/vmdk и прочим форматам?

о/п поднял вопрос best practice типичной установки, когда всем говорят - не используй thin без нужды, будет тормозить, не делай много снепшотов, будет тормозить, и спрашивает почему - я дал ответ почему. А то что для этих проблем существуют решения я прекрасно знаю и сам, только вот имплементация этих решений обычно даже не в thinLVM (который еще хреново пашет кстати) а в нормальном vm-aware storage типа Tintri или XtremIO. Только вот те кто таким пользуются, таких вопросов как в о/п не задают

может потому что оверселл, мы как-то лишних полтера навыдавали, в результате из-за нехватки пространства ушло несколько виртуалок. и пипец.