Основываясь на вашем вопросе и комментариях под ним, вы спрашиваете, стоит ли разделять пул между двумя дисками неравного размера. Короткий ответ: в этом нет ничего проблемного, если:
- Ваша рабочая нагрузка не критична к производительности. Если это так, используйте единый тип диска по всему пулу. В противном случае диски могут иметь разные характеристики производительности, что может создать очень тонкие проблемы с производительностью, которые трудно отследить. (Например, скажем, у вас есть два диска по 10K RPM, выпущенные одним и тем же поставщиком в одном году, один - 1 ТБ, другой - 2 ТБ. Нет проблем, верно? К сожалению, никто из них не получит удвоенную пропускную способность, хотя максимальное количество операций ввода-вывода в секунду будет одинаковым для дисков.)
- Вы в порядке без дополнительной избыточности. Обратите внимание , что в любой ситуации чередования, вы увеличиваете вероятность потери всех данных, потому что вы пошли с вероятностью одного диска не удается, к вероятности любым диск А или диск 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), и даже тогда, только когда вы увеличиваете производительность своей машины. Влияние на производительность обычно можно обойти, предоставив вашей виртуальной машине немного больше оперативной памяти.
