LINUX.ORG.RU

История изменений

Исправление 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 в другой пул устраняет текущую фрагментацию.