История изменений
Исправление sanyo1234, (текущая версия) :
Что, прямо до 50%? Это же треш какой-то. Ладно бы 10%,
Зависит от вида нагрузки. Например, нагрузка СУБД на ZFS+HDD может начать притормаживать, IMHO и начиная с 50% заполнения, после длительного использования и сильной фрагментации оставшегося свободного места.
а держать накопители полупустыми, чтобы скорость не падала. Ндаа.
Лучше не подключать сразу все диски, а подкидывать диски в пул (mirror vdevs ессно) по мере падения IOPs хранилища. Кроме того zfs send | zfs receive в другой пул устраняет текущую фрагментацию на получающей стороне, т.е. в реплике.
Исправление sanyo1234, :
Что, прямо до 50%? Это же треш какой-то. Ладно бы 10%,
Зависит от вида нагрузки. Например, нагрузка СУБД на ZFS+HDD может начать притормаживать, IMHO и начиная с 50% заполнения, после длительного использования и сильной фрагментации оставшегося свободного места.
а держать накопители полупустыми, чтобы скорость не падала. Ндаа.
Лучше не подключать сразу все диски, а подкидывать диски в пул (mirror vdevs ессно) по мере падения IOPs хранилища. Кроме того zfs send | zfs receive в другой пул устраняет текущую фрагментацию.
Исходная версия sanyo1234, :
Что, прямо до 50%? Это же треш какой-то. Ладно бы 10%,
Зависит от вида нагрузки. Например, нагрузка СУБД на ZFS+HDD может начать притормаживать IMHO и начиная с 50% заполнения после длительного использования и сильной фрагментации оставшегося свободного места.
а держать накопители полупустыми, чтобы скорость не падала. Ндаа.
Лучше не подключать сразу все диски, а подкидывать диски в пул (mirror vdevs ессно) по мере падения IOPs хранилища. Кроме того zfs send | zfs receive в другой пул устраняет текущую фрагментацию.