Для довольно полных и / или очень фрагментированных zpools я использую для включения отладки метаслабы (echo metaslab_debug/W1 | mdb -kw), чтобы избежать сбоя карты пространства и, как следствие, серьезного снижения производительности записи. Сама проблема вроде в старый и понял, по слухам, исправление "в работах" некоторое время так же, как и API дефрагментации, который, по-видимому, тоже должен помочь, но я не смог найти «официального» подхода, исправляющего его по умолчанию в производственном коде.
Я что-то упустил?
Некоторые данные среды: мои zpools имеют средний размер (обычно <10 ТБ) и в основном представляют наборы данных zfs с zvols, используя размер записи по умолчанию 8 КБ (который фактически является переменным из-за обычно включенного сжатия). На протяжении многих лет я наблюдал, как эта проблема появляется в разных версиях Solaris, особенно в устаревших zpool'ах, которые обрабатывают много данных. Обратите внимание, что это не то же самое, что zpool 90% full performance wall поскольку космическая карта ломается из-за попаданий фрагментации при значительно более низком уровне использования пространства (я видел, что это происходило на 70% на нескольких старых пулах)
К сожалению, одним словом: нет.
Одним словом: вроде как. Метод, с помощью которого ZFS находит свободное пространство для использования, был несколько изменен в последних сборках ZFS (Open-ZFS), чтобы несколько смягчить проблему - основная фрагментация остается, «исправление» заключается в том, что она меньше влияет на производительность.
Единственное истинное «исправление», которое вы можете использовать на данный момент, - это отправить zfs данные из пула, стереть пул и zfs отправить данные обратно. Очевидно, проблема снова появится позже, в зависимости от вашей рабочей нагрузки и того, насколько быстро вы фрагментируете космические карты.
Обсуждаются / разрабатываются и другие возможные исправления / обходные пути, но я, конечно, не смог назвать никакого ETA.