Основываясь на вашем вопросе и комментариях под ним, вы спрашиваете, стоит ли разделять пул между двумя дисками неравного размера. Короткий ответ: в этом нет ничего проблемного, если:
- Ваша рабочая нагрузка не критична к производительности. Если это так, используйте единый тип диска по всему пулу. В противном случае диски могут иметь разные характеристики производительности, что может создать очень тонкие проблемы с производительностью, которые трудно отследить. (Например, предположим, что у вас есть два диска по 10 000 об / мин, сделанные одним и тем же поставщиком в один и тот же год, один из которых составляет 1 ТБ, а другой - 2 ТБ. Нет проблем, верно? К сожалению, никто из них не получит ~ удвоить пропускную способность, хотя максимальный IOPS будет одинаковым между дисками.)
- Вы в порядке без дополнительной избыточности. Обратите внимание, что в любой ситуации чередования, вы увеличиваете вероятность потери всех данных, потому что вы пошли с вероятностью одного диска не удается, к вероятности любым диск A или диск B (или оба) неисправные. Даже если ZFS хранит несколько копий метаданных, а случайная ~ половина данных отсутствует, вам будет нелегко восстановить многие полные / пригодные для использования файлы из вашего пула.
Тем не менее, есть все еще неразумные способы установить это. Если один из дисков является SSD, а другой - HDD, чередование разрушит прирост производительности, который вы получили от использования SSD, и, вероятно, очень расстроит вас. В этой ситуации я бы порекомендовал либо:
- Используйте больший жесткий диск в качестве «основного диска с данными», а затем разделите твердотельный диск на два раздела: один большой раздел, используемый в качестве устройства L2ARC (
cache) для ускорения чтения часто читаемых данных, и один маленький раздел, используемый в качестве ZIL (log) устройство для ускорения синхронных задержек записи. Это решение хорошо, потому что оно автоматически кеширует самые полезные данные на SSD, так что вам не нужно слишком задумываться о его балансировке. Кроме того, вы потеряете все свои данные только в том случае, если потеряете жесткий диск в этом случае (вы можете потерять до нескольких секунд записи, если SSD умрет, но это намного лучше, чем все ваши данные, как в случае с чередованием выше) , - Создание отдельного пула для каждого диска и ручное сохранение содержимого, которое вы хотите быстро (ОС, исполняемые файлы, библиотеки, подкачка и т. Д.) На SSD, и содержимого, которое нормально работает медленно (фильмы, фотоальбомы и т. Д.) На жестком диске. Это лучше всего, если машина будет часто перезагружаться, потому что данные, кэшированные в L2ARC, не сохраняются при перезагрузках. (Это большая слабость в текущей истории L2ARC для персональных компьютеров IMO, но над ней активно ведется работа.) С точки зрения избыточности вы, очевидно, потеряете только то, что было на диске, который вышел из строя.
Редактировать, так как эти диски виртуализированы
Поскольку это виртуальная машина, если вы не указали специальные параметры для производительности дисков, ни один из приведенных выше критериев производительности / избыточности не должен препятствовать созданию пула с двумя несовпадающими размерами дисков. Однако управлять им будет намного проще, если вы просто используете свою платформу виртуализации для изменения размера исходного диска до суммы предлагаемых размеров диска. Чтобы использовать это дополнительное пространство в гостевой системе, вам нужно будет запустить zpool online -e <pool> <disk>, и, поскольку это ZoL, вам, возможно, придется сначала исправить таблицу разделов, как в инструкциях здесь .
Вы должны строго предпочесть этот подход из-за простоты управления, но один очень незначительный недостаток заключается в том, что при изменении размера ZFS не может изменить размер метаслаба. Метаслабы - это внутренняя структура данных, используемая для распределения дискового пространства, и до самого недавнего времени ZFS всегда создавала 200 из них на диск независимо от размера диска (продолжается работа по его улучшению). Поэтому, когда вы увеличиваете размер диска с очень маленького до очень большого, вы можете получить очень большое количество метаслаб, которое использует немного больше оперативной памяти и немного больше дискового пространства. Это не заметно, если только размер диска не меняется очень сильно (например, 10G -> 1T), и даже тогда, только когда вы увеличиваете производительность своей машины. Влияние на производительность обычно можно обойти, предоставив вашей виртуальной машине немного больше оперативной памяти.