YURKAМеня интересуют рекомендации по оптимальному свободному дисковому пространству.Для чего, для сиквела, или для других целей?

Для сиквела (то есть для томов ФС, которые используются исключительно для файлов данных и лога сиквела) не нужно свободного пространства; после создания файлов, метаданные ФС не меняются, фактически всю свою жизнь сиквел оперирует раз и навсегда выделенным набором секторов, и, соответственно, никакого значения заполненность диска не имеет. Разумеется, если вам не надо менять размеры файлов, или создавать новые.

А если речь о ФС для Windows, то про это спрашивайте в другом разделе форума. Я бы держал для виндов свободными не менее 10%, и не менее 50Гб, если там ещё нет каких то приложений.

Владислав КолосовЕсли не ошибаюсь это связано с эффективностью фоновой работой дефрагментатораЧто делает дефрагментатор на диске для файлов данных сиквела, на котором, возможно, находится единственный, созданный при инсталляции, файл, размером с весь диск? (ну, или несколько файлов).

Это каким чайникам нужно доверить админить сиквел, что бы на этом диске потребовалась дефрагментация?
Это надо держать там тыщу баз, и каждый день делать им всем шринк, вот тогда, через годик... :-)

YURKAРекомендации по минимальному дисковому пространству MS SQL 2016.Прикольно :-)
Тогда " Рекомендации по минимальному дисковому пространству MS SQL 2016" звучат как: "дисковое пространство должно быть достаточным для размещения файлов данных и логов БД, при исключении "сжатия" файлов, как регулярной операции обслуживания БД"

982183Для SSD свободное место критично для его сохранности.
Ибо постоянная перезапись в одни и те же свободные ячейки приводит к их "износу".Никаких постоянных записей в одни и те же свободные ячейки там не происходит.
SSD равномерно распределяют запись по ячейкам, и ресурс записи определяется ресурсу ячейки * емкость, независимо от размера незанятого пространства.

aleks222alexeyvgЧто делает дефрагментатор на диске для файлов данных сиквела, на котором, возможно, находится единственный, созданный при инсталляции, файл, размером с весь диск? (ну, или несколько файлов).
Наивняк.
1 (одна) FileTable c "относительно" интенсивной перезаписью - и фсе.
Неделя работы и дефрагментатор показывает охереннную фрагментацию.
И хрен бы с ней, но! бэкап начинает жаловаться и не выполняется.Не, ну FileTable - это как бы не сиквел :-)
Я бы FileTable размещал, по возможности, на отдельном диске (где должен быть запас, и где нужно делать дефрагментацию), ну или на диске с данными, но тогда там должно быть достаточно свободного места.
Кстати, в зависимости от размера файлов, может понадобиться подобрать размер кластера не такой, как для сиквела.

uaggster982183Для SSD свободное место критично для его сохранности.
Ибо постоянная перезапись в одни и те же свободные ячейки приводит к их "износу".
Это только если перезапись очень высокочастотная.
Так то, обычно, пишется в SLC кэш, а уже потом - в рабочую область.Больше того, одни и те же ячейки могут использоваться как SLC, MLC, TLC, в зависимости от потребностей.
Плюс делается перенос меняющихся данных, т. е. происходит обмен ячейками между блоками, в которые не пишут, и блоками, в которые пишут.

982183alexeyvgпропущено...
Никаких постоянных записей в одни и те же свободные ячейки там не происходит.
SSD равномерно распределяют запись по ячейкам, и ресурс записи определяется ресурсу ячейки * емкость, независимо от размера незанятого пространства.


SSD равномерно распределяют запись по СВОБОДНЫМ ячейкам,
И если на SSD кроме базы есть система или кэш, а места не так много,
то частота этих записей/освобождений сильно возрастает.Начнём с того, что в топике обсуждается свободное пространство ФС. А его SSD считает занятым, у него же нет сведений о файловой системе.
Так что, если у вас половина ФС свободна, то SSD, по вашей логике, должен брать ячейки для записи из своего резерва, и никогда не делать запись в пространство, не занятое файлами, потому что для SSD оно занято.

Да, раньше так и делалось, во времена SLC, но сейчас, когда ресурс ячейки составляет 500 циклов (и это в лучшем случае!), производителям пришлось придумывать новые алгоритмы, для равномерного распределения износа ячеек.
Что неизбежно привело к использованию в этих алгоритмах занятых, но реально неиспользуемых ячеек (например, пустого пространства файловой системы, или занятого, но долго не перезаписываемого - что для SSD-контроллера одно и то же).
Для TLC памяти это просто неизбежно, ибо в противном случае пришлось бы делать резерв больше чем в 2 раза, что слишком дорого.

Так что, с учётом вышесказанного, даже не вникая в алгоритмы распределения записи по ячейкам, можно смело оставлять 0 свободного пространства в томе ФС, потому что для SSD там и так 0 свободного пространства.

alexeyvgА его SSD считает занятым, у него же нет сведений о файловой системе.Уточню, с TRIM это не так, но TRIM может не поддерживаться рейд-контроллерами.