У меня есть этот пул ZFS, состоящий из двух зеркальных дисков Samsung 870 QVO емкостью 1 ТБ, которые я использую около года для хранения гостевых образов bhyve в виде ZVOL.За это время я создал / испортил / уничтожил множество экземпляров виртуальных машин; этот пул видел довольно много дисковой активности.
Прошлой ночью, глядя на производительность дискового ввода-вывода на одной из виртуальных машин, я понял, что никогда раньше не обрезал эти SSD. Не совсем зная, чего ожидать, я выключил виртуальные машины и запустил отделка zfs в бассейне.
В целом вся операция заняла колоссальные 16 часов (!) Для справки вот что gstat-pdo должен был сказать за это время (типичный вывод со значениями, усредненными за 10 с):
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d o/s ms/o %busy Имя
11 45 0 0 0,0 27 292 84,9 18 8497 114,3 0 82,9 101,0| ада0
12 37 0 0 0,0 26 283 92,1 11 6547 189,1 0 84,2 100,6| ада1
В любом случае, я терпеливо довел дело до конца.
Затем, сегодня утром, когда все виртуальные машины все еще остановлены, я решил запустить отделка zfs еще раз. Я полагал, что, поскольку с момента последнего TRIM в этом пуле не было значительной активности, а большая часть нераспределенных блоков предположительно была освобождена контроллером SSD в первый раз, на этот раз это будет намного быстрее.
Что ж, моя интуиция ошиблась: этот ТРИМ работает уже около 5 часов, и, согласно статус пула -t, выполнено чуть более 30%. Так что, по-видимому, я смотрю на похожее общее время работы (~ 16 часов, плюс-минус).
Ожидается ли такое поведение? Потому что если это так, то, очевидно, я что-то упускаю из того, как работает TRIM.
Примечания:
- Я знаю о недостатках серии QVO (4-битная флэш-память MLC, заведомо малый объем псевдо-SLC-кэша), поэтому я не ожидал какой-либо сумасшедшей производительности с самого начала.
- Возможно, что-то не так с моей настройкой (плохой кабель SATA и т. д.), но тем не менее это не объясняет, почему система не получает преимуществ от предыдущих запусков TRIM в том же пуле.
