Прежде всего: я не собираюсь рассуждать о развитии через 6-7 лет. Это о сегодняшнем дне и ближайшем будущем. Для TL;DR см. Нижнюю часть этого ответа.

ZFS сегодня не позволяет вам удалить vdev из пула. Он также не имеет никакой встроенной функции "перебалансировки" (ищите перезапись блочного указателя, переписывание bp или переписывание bpo, чтобы узнать больше об этом). ZFS позволяет вам снизить уровень избыточности зеркального, но не raidzN, vdev, но это не то, что вам нужно. (В ZFS чередование - это то, что вы получаете, когда ничего не говорите.)

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

Когда у вас есть "зеркальный" пул, такой как тот, который вы описали после первого расширения, у вас действительно есть два vdevs, каждый из которых состоит из зеркальной пары физических устройств хранения, где два vdevs чередуются для формирования пула. Пул с двумя-vdev два диска-каждого-зеркала может быть отключен одним неисправным диском и одной неудачной ошибкой на другом диске в этом наборе зеркал, даже если другой комплект зеркал работает отлично. В случае такого сбоя, что бы ни случилось, вы потеряете некоторые данные.

Обычный способ увеличения емкости в пуле ZFS - заменить имеющиеся диски на более крупные, разрешить повторное размещение пула на новом диске и затем физически удалить старый диск, который больше не используется. Обычно человек хочет использовать zpool replace для этого нужно подключить как старый, так и новый диск, чтобы поддерживать желаемый уровень избыточности на протяжении всего процесса. Обычная альтернатива - добавить vdevs с тем же уровнем избыточности, что и существующие vdevs в пуле. Опять же, обратите внимание, что поскольку ZFS не поддерживает удаление части чередующегося набора, а пулы состоят строго из чередующихся vdevs, вы не можете удалить vdev, как только добавите его. Многие новички в ZFS попадают в эту ловушку, и легко запутаться, если вы не обращаете внимания на те команды, которые вы используете.

Из-за того, как работают ресиверы ZFS, результирующее больно мучительно для задействованных накопителей. В то время как традиционные преобразователи RAID обычно в основном последовательные, с небольшим количеством случайных операций ввода-вывода, чередующихся с пользовательской активностью, резервирующие устройства ZFS являются практически полностью случайными операциями ввода-вывода, чередующимися со случайными операциями ввода-вывода в результате пользовательской активности. Зеркальный набор видел в значительной степени ту же самую деятельность в течение своей жизни; если один диск маргинальный или даже умер, вполне возможно, что другой диск также в лучшем случае маргинальный. То, что оно будет страдать от повторяющихся испытаний в течение многих дней, может очень легко толкнуть его через край. (Исходя из личного опыта, я бы предположил, что для повторной обработки 6 ТБ данных вы смотрите на процесс восстановления приблизительно на неделю. Даже если вы поверните все ручки до 11, основываясь на чистой последовательной пропускной способности - Абсолютно нереально, учитывая формат ZFS на диске и стратегию повторного использования - вы ожидаете не менее 17 часов ужаса для накопителя. Мое лучшее предположение состоит в том, что не было бы никакого способа добиться снижения резольвера 6 ТБ до менее чем может быть, вдвое больше, или полтора дня, от прямого злоупотребления.)

У меня также были бы очень серьезные сомнения относительно конфигурации зеркала 2x24 ТБ или даже 2x12 ТБ, предполагая, что такие диски материализуются; мы уже немного раздвигаем границы физики (без каламбура) с текущими размерами дисков. Если предположить, что надежность диска, с точки зрения URE, остается аналогичной сегодняшней (от 10^-14 до 10^-15 ошибок сектора на чтение бита, и это то, где она постоянно, как и всегда, в листах данных производителя), статистически вы не будете возможность выполнить полное чтение вашего диска 12 ТБ, не обнаружив хотя бы одной ошибки (12 ТБ - это примерно 9×10^13 бит, что хорошо округляется до 10^14). К тому времени, когда вы добавите это на диски емкостью 24 ТБ, статистически вы получите по крайней мере одну или две ошибки полного сектора за один проход полного чтения (потому что вы читаете около 2*10^14 бит). Даже если вы используете 10^-15 дисков URE, это не будет вам дорого стоить (тогда вы смотрите на пять проходов чтения, а не половину прохода чтения). Это, конечно, статистика и спецификации; на практике ошибки чтения имеют тенденцию объединяться в кластеры, и накопитель может обеспечить бесперебойную работу для многих, многих полных операций чтения, прежде чем он в какой-то момент начнет выдавать ошибки влево и вправо и в центр.

Учитывая, что большинство несерверных спиннеров имеют гарантию только на 1-3 года, я бы не стал рассчитывать, что какой-либо набор будет продолжать работать гораздо дольше этого, в то время как ваш план требует, чтобы они оставались работоспособными в течение как минимум шести лет, прежде чем их заменят., Даже серверные счетчики обычно имеют гарантию только на пять лет, хотя обычно на работу в режиме 24x7 обычно пять лет. Мой личный опыт показывает, что высокопроизводительные потребительские накопители, такие как серия Constellation ES от Seagate, могут обеспечить почти такой уровень обязанностей, прежде чем отказаться от призрака и попасть в рай для данных. (Личный анекдот: Созвездие 1 ТБ ES.2 У меня было что-то вроде 4 лет 9-10 месяцев к тому моменту, когда он начал вести себя забавно, хотя я никогда не доводил это до отказа.)

В общем, учтите, что многие люди, использующие ZFS, используют двойную избыточность после того, как размеры блесны достигают отметки 3-4 ТБ или меньше для получения более важных данных. Для этого есть веская причина: устройства хранения данных выходят из строя, и это происходит с пугающей частотой. В случае ZFS вы также обращаете внимание на гораздо более дорогие сервисы восстановления данных, если вам нужно что-то помимо того, чтобы возвращать вам необработанные биты, которые все еще доступны для чтения с пластин, и я не знаю ни о каком программном обеспечении для восстановления данных, которое может даже удаленно обрабатывать пулы ZFS. Если ZFS не может импортировать ваш пул, наиболее практичным ответом часто будет считать потерянные данные, которые вы не создавали в другом месте.

Ответить на заглавный вопрос и TL;DR

Позволит ли FreeNAS/ZFS мне управлять моим хранилищем таким образом

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