# Типы дисков в ZFS. Прокачиваем наш RAID при помощи SSD **URL:** \ **Category:** NAS. Сетевые хранилища\ **Tags:** truenas\ **Created:** [29.Ноябрь.2025 12:30:14 UTC](https://forum.samohosting.ru/t/tipy-diskov-v-zfs-prokachivaem-nash-raid-pri-pomoshhi-ssd/1363 "2025-11-29T12:30:14Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\ **Post date:** [29.Ноябрь.2025 12:30:14 UTC](https://forum.samohosting.ru/t/tipy-diskov-v-zfs-prokachivaem-nash-raid-pri-pomoshhi-ssd/1363/1 "2025-11-29T12:30:14Z")
Рассмотрим варианты ускорения (и вообще прокачки) ZFS пула при помощи SSD дисков В данном случае я рассматриваю на примере TrueNAS т.к. использую его в качестве NAS, но это будет применимо и для других систем на основе ZFS Рассмотрим типичный ZFS пул ![image](https://forum.samohosting.ru/uploads/default/original/2X/c/c4ae2ede0f4c2b8f760711953f844b666dca0419.png) Минимально у нас должны быть Data VDEVs, это обычные диски с данными, на основе которых строится массив. В зависимости от топологии массива у нас может присутствовать ускорение операций чтения или записи, но может и замедляться, поэтому надо разбирать топологию ([вот тут есть калькулятор](https://www.raidz-calc.ru), можно поиграться с ним самотоятельно т.к. это выходит за рамки данного поста (но по просьбам желающих могу ниже что-то написать подробнее)) Давайте будем исходить из отказоустойчивых топологий, в которых скорость записи в лучшем случае будет соответствовать скорости записи на 1 диск, а ускорение чтения будет от N-2 до N раз. Т.е. мы понимаем, что при использовании обычных жестких дисков, особенно маленького объема (до 10 ТБ) и при интенсивном использовании нашего массива в хомлабе, мы будем упираться в скорости (что не притно, но жить можно) и в IOPS (что уже может быть очень критично), особенно когда наш NAS используется для хранения виртуалок и служебных файлов для кучи сервисов > **Что такое IOPS** > Input/output Operations Per Second - количество операций позиционирования головки над определенным сектором и чтение/запись этого сектора за единицу времени. При интенсивных случайных операциях ввода-вывода, например, торренты, виртуалки, несколько сервисов, хранящих данные на диске диск будет постоянно позиционироваться в разных местах и иметь задержку на выполнение этой операции > **Типовые IOPS для HDD** > > - **5400 RPM (обычные “Green / Archive” диски)** - IOPS: 60–90, задержки: ~15–17 мс > - **7200 RPM (рабочие SATA, NAS и десктопные)** - IOPS: 90–150, задержки: ~12–14 мс > - **10 000 RPM SAS (HDD enterprise-класса)** - IOPS: 140–200+, задержки: ~8–10 мс **Для SSD** - **SATA SSD (2.5", 6 Gb/s)** - IOPS: 50 000 - 100 000, задержки: ~80–120 мкс - **NVMe SSD (PCIe)** - IOPS: 300 000 – 550 000, задержки: **20–40 мкс** , иногда до 15 мкс И сводная таблица | Тип накопителя | IOPS чт./зап. | Латентность | Sequential MB/s | | --- | --- | --- | --- | | **HDD 7200** | 100–150 | 12–14 ms | 150–220 | | **SATA SSD** | 70k–100k | 80–120 µs | 550/550 | | **NVMe PCIe 3.0** | 300k–550k | 20–40 µs | 3 500 / 3 000 | | **NVMe PCIe 4.0** | 600k–1M | 10–20 µs | 7 000 / 6 000 | | **NVMe PCIe 5.0** | 1.0–1.5M | \<10 µs | 14 000 / 12 000 | | **Intel Optane** | 0.5M–1.1M | 6–10 µs | ~2 500 | И тут мы можем задать вопрос: а может быть можно как-то ускорить наш массив за счет гибридной технологии? > Одно время на рынке даже были HDD диски со встроенным SSD (так называемые SSHD), для системы они выглядели как обычные диски, однако, запись была сначала на SSD, с последующим фоновым сбросом на HDD и при чтении они могли кешировать блоки HDD диска на встроенный SSD > Однако, они так и не прижились за счет низкого качества, малого объема SSD диска и примитивных микропрограмм контроллера, которые часто делали только хуже при цене, соизмеримой с отдельной парой HDD + SSD Итак, вернемся к основной теме нашей статьи: как можно прокачать массив при помощи SSD. Для этого у нас есть несколько типов специальных дисков (special vdev): - **log (SLOG)** - ускоряет синхронную запись, фактически, запись происходит на быстрый SSD с последующим фоновым сбросом данных на HDD - **cache (L2ARC)** - кеширование чтений, расширяет ARC (RAM), при чтении блоков данных (может и при записи) происходит запись в этот диск, а при чтении данных ZFS читает из SSD диска, минуя HDD - **metadata (special vdev / special\_small\_blocks)** - Хранит метаданные (список файлов) и маленькие файлы, что значительно ускоряет листинг каталогов - **dedup (DDT location)** - непосредственно на скорость не влияет, однако при включении дедупликации позволяет снизить нагрузку на оперативную память, а сама дедупликация в том числе может косвенно влиять на скорость (снижая лишние чтения и запись) ### Сводная таблица для пула на 6ТБ | Тип vdev / роль | Назначение (когда полезно) | Типичный пример использования | Рекоменд. размер для пула ~6 ТБ | Рекомендуемая надёжность (надежность / при отключении) | Можно удалить? / как влияет при отказе | | --- | --- | --- | --- | --- | --- | | **data (обычные vdev)** | Основные данные (файлы). | HDD vdev (raidz1/2/10) — всё основное. | N/A (основной пул на HDD). | Должна быть отказоустойчивая конфигурация (mirror/raidz). При потере vdev — потеря данных. | Нельзя удалить без перестроения/перевода данных. | | **log (SLOG / separate log)** | Быстрые подтверждаемые (synchronous) записи (NFS sync, databases, PBS). Ускоряет sync-writes. | NVMe/SATA SSD с высокой надежностью и энергозащитой (PLP). | Маленький: обычно 8–64 GB в зависимости от паттерна sync-транзакций (PBS рекомендует SLOG для NFS). Для 6 ТБ пула — чаще 16–64 GB достаточно. | Должен быть **зеркалом** (mirror) для надёжности; лучше NVMe с PLP. При потере single SLOG — синхронные записи будут писать в основную pool log area → производительность упадёт, но данные не обязательно потеряны (если не было подтверждённых транзакций на SLOG). | **Можно удалить** (в новых версиях OpenZFS поддерживается удаление лог-vdev), но не рекомендуется в рабочей среде без плана: удаление прекращает ускорение sync-writes; при отказе single SLOG возможна потеря ускорения и риск незавершённых транзакций. | | **cache (L2ARC)** | Кеширование чтений, расширяет ARC (RAM). | SSD как L2ARC для ускорения случайных чтений/горячих блоков. | Обычно 5–10% от пула данных для общего ускорения чтений; для 6 ТБ → 300–600 GB ориентировочно. Но на практике 64–256 GB часто даёт заметный эффект при небольшом объёме горячих данных. | Кеш — неблокирующий: отказ → падение производительности чтения, данные не теряются. | **Можно удалить** (без потери данных). L2ARC активно перезаписывается — ускоряет чтения, но сокращает ресурс SSD при интенсивных записях. | | **metadata (special vdev / special\_small\_blocks)** | Хранит метаданные (иноды, директории, небольшие блоки) и (при включении) DDT (dedup table). Ускоряет операции с большим количеством мелких файлов/метаданных. | SSD/ NVMe special vdev для пулов с большим количеством мелких файлов/git/контейнерных образов/много мелких random IO. | Часто 0.5–2% пула для чисто метаданных; если много мелких файлов и вы хотите поместить также DDT → 1–5% или больше. Для 6 ТБ: **64–512 GB** в зависимости от плотности мелких файлов и включения dedup/DDL. | **Нужно дублировать** (mirror/raidz) — потеря special vdev может сделать пул нестабильным/неполнофункциональным, т.к. теряются критичные метаданные. | **Нельзя удалить** из пула (special vdev не удаляем). При отказе — серьёзные последствия, поэтому делать зеркалирование/избыточность обязательно. | | **dedup (DDT location)** | Ускорение/экономия места при дублировании данных (очень RAM-зависимо). | Только при реальной высокой дубликации и наличии большого объёма RAM и/или DDT на fast SSD. | DDT размер зависит от объёма и уникальных блоков; не задаётся как % пула — нужно тестировать. Если планируете dedup, разместите DDT на special vdev. | Dedup сильно влияет на RAM; без резервирования отказ DDT → медленная работа. | Dedup можно отключить, но реал-влияние и удаление DDT требует переразмещения данных; не тривиально. | ## Поведение при отказе / удалении — кратко - **Cache (L2ARC)**: отказ безопасен — просто теряете кеш. Можно добавлять/удалять без последствий для данных. - **Log (SLOG)**: без SLOG pool продолжит работу, но синхронные операции станут медленнее (они вернутся к поведению без отдельного SLOG). Если SLOG был single и умер в момент подтверждения транзакции — есть риск проблем с незавершённой транзакцией; поэтому SLOG лучше ставить в зеркало. - **Special (metadata)**: отказ критичен. Special-vdev хранит метаданные и небольшие блоки; потеря может привести к повреждению метаданных и невозможности доступа. Поэтому special должен быть зеркалом/raidz и размещён на надёжных SSD. **Special нельзя удалить** (по вашим наблюдениям — подтверждается практикой OpenZFS). - **Dedup (DDT)**: размещение DDT на fast special-vdev улучшает производительность, но в случае отказа без зеркалирования можно получить проблемы. Dedup обычно не рекомендую на пуле без большого объёма RAM. ## Рассмотрим варианты комбинации дисков Сравнение комбинаций (кратко, практические выводы) ### `special` + `log` - **Смысл** : да — дополняют друг друга. `special` ускоряет доступ к метаданным и мелким блокам (git, docker, множество small-file операций). `log` ускоряет synchronous writes (NFS, PBS, databases). - **Когда полезно** : если у вас и много мелких операций (иноды, метаданные) и есть синхронная нагрузка (PBS NFS, DB). Для вашей конфигурации (PBS + git/docker + NFS) — комбинация оправдана: special для responsiveness git/docker, slog для PBS/NFS. - **Предложение** : сделать **mirrored NVMe** для special (например 2 × 240–500 GB) + **mirrored SLOG** (две NVMe/SSD с PLP, 32–64 GB или больше, в зависимости от размера транзакций). ### `cache (L2ARC)` + `special` - **Смысл** : частично дублируют эффект, но не одинаково. Special ускоряет метаданные и мелкие блоки на постоянной основе (они всегда хранятся на fast device), L2ARC хранит hot read-blocks (периодически перезаписываемый кеш). Если у вас много мелких случайных чтений, оба могут помочь; но special даёт более надёжный и постоянный эффект. - **Когда не стоит** : если L2ARC будет намного меньше рабочего набора горячих данных и/или он будет активно перезаписываться (media пул — много больших файлов → L2ARC быстро перезаписывается → SSD wear). - **Предложение** : для _data_ (git/docker + fotos) — special приоритетнее. L2ARC как доп опция если у вас есть горячий набор файлов чтений, и у вас достаточно RAM (ARC) — иначе L2ARC эффективность низкая. ### `log` + `cache` - **Смысл** : независимы: log ускоряет записи, cache — чтения. Оба полезны в разных сценариях. Если бюджет ограничен — приоритет SLOG для PBS/NFS и special для мелких файлов; L2ARC — опционально. ## Выводы - Определенные типы дисков позволяют ускорять определенные типы операций, надо понимать характер искользования пула, например, если вы используете L2ARC на 50ГБ для чтения установочных ISO на 10ГБ + git репозиториев на 10 ГБ + фотографии на 20ГБ, то есть шанс, что большая часть чтений будет происходить с кешем, если же вы раздаете 500ГБ контента, то L2ARC будет все время переполнен и SSDшник будет просто изнашиваться без ускорения чтения т.к. каждый новый блок данных будет читаться с диска и записываться на SSD, а через мгновение новый блок, вытесняя предыдущие. - Некоторые типы дисков критичны и требуют дублирования т.к. при потере диска есть шанс потерять весь массив - Некоторые типы дисков после добавления нельзя удалить (по крайней мере через web интерфейс TrueNAS, GPT говорит, что в новых версиях OpenZFS можно сделать из консоли, но это не точно) - Добавление диска в пул не приводит к переносу на него данных, это значит, что эффект сразу не увидим, для cache и slog мы увидим быстро результат, особенно для slog, а вот metadata + small blocks только новые файлы будут попадать на новые диски, старые же будут оставаться на data vdev - Многие слышали, что ZFS любит кушать оперативную память и это правда, если оперативной памяти мало, то ZFS пул начинает сильно деградировать по скорости, добавление SSD дисков не только ускоряет работу пула, но и снижает требования к оперативной памяти. ## Личной мой опыт - Мне помогло то, что у меня сейчас 4 пула под разные задачи и они содержать разные SSD диски, подробности ниже - Матрешка PVE → TrueNAS помогла тем, что чать SSD дисков я подключаю к хосту, там разбиваю диск на несколько разделов и уже эти разделы прокидываю в TrueNAS, что позволяет сократить количество SSD дисков, например, 1 диск на 512 режится на 2 по 256 + какой-то остаток, при замене SSD диска на новый, если там размер будет чуть меньше, то можно будет сыграть на этом пусом месте - NVME диски, не использую, только 2.5 SATA в [таком боксе](https://ali.click/o2rgrm) (он не идеален) - Производительность реально выросла, причем, на каки-то эпизодических операциях типа работы с git или фотками я перестал видеть разницу по сравлению с SSD ## Примеры из жизни 1. Скидывание 1ГБ фоток в immich раньше занимало довольно долго времени т.к. в секунду примернно сохранялось 1-2 фотки, а стали прям влетать как по маслу 2. Forgejo при коммите была зареждка секунд 5 пока мелкие файлы раскидаются по дискам, при открытии репозитория в веб интерфейсе список файлов и каталогов мог подгружаться несколько секунд, сейчас это стало происходить в большинстве случаев мновенно 3. PBS в ввиде виртуалки и NFS шарой для бэкапов и 600 резервными копиями список грузил до минуты, собственно с этого и 2 пункта у меня пошел процесс прокачки, после переноса PBS в LXC контейнер и добавления SSD время листинга сократилось до пары секунд максимум, часто это происходит моментально 4. Создание бэкапа размером 17.86ГБ занимает 3 минуты 12 секунда от запуска до финиша ## Ну и мои параметры SSD дисков для каждого типа пула ### По пулам - Бэкапы - metadata + small blocks + slog для быстрого листинга файлов и чтения файлов с метаданными + slog для быстрого создания бэкапа, cache не стал добавлять т.к. он при чтение бэкапов тоже активное и кеш будет постоянно в режиме перезаписи - Общие данные (фотки, гит, документы, образы дисков, помойка, короче) - добавил все, кроме dedup (dedup включал на датасете с фотками где очень много дублей, типа папка разобрать, папка SD карточки, папка с разобранными фотками) - Media (фильмы, аудиокниги, музыка) - только данные без SSD т.к. смысла в metadata нет - файлы большие, slog не то, чтобы критично, cache будет постоянно переполнен - NVR - аналогично Media, последовательная запись с эпизодисеским чтением файлов, при этом список файлов все равно на стороне Frigate, в теории можно добавить metadata, но выделять под это 2 SSD диска (или раздела на них) не вижу смысла Графики по пулам, тут видно, что Media и NVR упираются в IOPS жесткого диска (порядка 80 для 5400), Data и Backups переваливают за 1000 IOPS ![image](https://forum.samohosting.ru/uploads/default/original/2X/b/ba81a1fdd22a516c61366d7c6e62facc60702b1a.jpeg) ### По типам дискв 1. Data - некоторые с дублированием RAIDz, но для NVR и Media потеря данных явно не так критична, как потеря фоток 2. Cache VDEV - один SSDшник, тут вообще не критично 3. Metadata + small blocks - Mirror т.к. потеря SSD приведет к неработающему RAID массиву 4. Slog, по хорошему тоже надо mirror, но мне жалко еще один SSD втыкать, у меня и так 4 штуки воткнуто, потеря SSD приведет максимум в потере файлов, записанных в течение последних минут, по идее, S.M.A.R.T. должен выдать алерты и дать возможность сбросить slog еще до того, как диск отвалится полностью ## Что думаю на будущее У меня есть 1.5ТБ фоток в `/data/photos` (писал, что там свалка) сейчас начал активно осваивать immich (для новых фоток уже года 1.5 использую, а вот старые пока особо не выгружал в него), вот думаю включить dedup для `/data/immich`, возможно надо будет гигов 10 добавить SSD туда чтобы в процессе перетаскивания фоток из `/data/photos` в immich эти фотки не занимали 2 раза место на моем массиве, а за счет дедупликации просто были ссылки на них. В целом, дедупликация это не самая удачная вещь в плане производительности как добавляет еще один слой маппинга данных, но место экономит прилично ## Последние замечания 1. RAID не гарантирует сохранности данных, правило 3-2-1 не разрешает нам отказаться от классических бэкапов при хранении данных на RAID массиве, можно как минимум добавить синхрониацию с другими дисками, холодное хранилище на сменных дисках и синхронизацию с облаком 2. У меня сейчас 4 пула в TrueNAS, с одной стороны это усложнение и увеличение количества SSD дисков, с другой стороны это позволяет лучше тюнить пулы в зависимости от нагрузки + увеличить количество IOPS, так QBT с огромным iowait и очередью в секундых никак на влияет на работу других пулов, а бэкапирование я тоже не ограничивал по скорости т.к. интентивная запись бэкапов не влияет на скорость доступа к фоткам и git ---
**Author:** ![Vovec](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/vovec/32/78_2.png) [@Vovec](https://forum.samohosting.ru/u/Vovec)\ **Post date:** [29.Ноябрь.2025 13:22:10 UTC](https://forum.samohosting.ru/t/tipy-diskov-v-zfs-prokachivaem-nash-raid-pri-pomoshhi-ssd/1363/2 "2025-11-29T13:22:10Z")
Спасибо за разбор. Очень интересно. > [@KRom](#): > > поэтому надо разбирать топологию (вот тут есть калькулятор, можно поиграться с ним самотоятельно тут - наверное, предполагалась ссылка? ---
**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\ **Post date:** [29.Ноябрь.2025 13:22:23 UTC](https://forum.samohosting.ru/t/tipy-diskov-v-zfs-prokachivaem-nash-raid-pri-pomoshhi-ssd/1363/3 "2025-11-29T13:22:23Z")
Ради эксперимента, и для развлечения сообщества таки добавил спорный dedup vdev ![image](https://forum.samohosting.ru/uploads/default/original/2X/b/bee29488cdfb6ced613594c554031bfcd511aadf.png) > Data Vdev с предупреждением Mixed Capacity это потому что я в процессе миграции пула на диски большего объема **Пул содержит 3 HDD диска с данными и 6 SSD дисков буста** Dedup таблица занимает приблизительно 1% от оригинальных данных, т.е. 16ГБ должно хватить для удаления 1-2 ТБ дублей из пула (Увеличивается Usable Capacity) > [@Vovec](#): > > тут - наверное, предполагалась ссылка? Да, спасибо за уточнение, действительно, забыл вставить Вот пример ![image](https://forum.samohosting.ru/uploads/default/original/2X/6/63528fce1f893819338cd8ace6cfc7f51ea3626c.png) Есть еще [вот такой](https://wintelguy.com/zfs-calc.pl) калькулятор, он выводит больше данных по объему, но без ускорений ---
**Author:** ![Garrett](https://forum.samohosting.ru/letter_avatar_proxy/v4/letter/g/3e96dc/32.png) [@Garrett](https://forum.samohosting.ru/u/Garrett)\ **Post date:** [29.Ноябрь.2025 13:36:10 UTC](https://forum.samohosting.ru/t/tipy-diskov-v-zfs-prokachivaem-nash-raid-pri-pomoshhi-ssd/1363/4 "2025-11-29T13:36:10Z")
Спасибо, познавательно. > [@KRom](#): > > что при использовании обычных жестких дисков, особенно маленького объема (до 10 ТБ) `Я правильно понимаю, что 1 - 10 ТВ считаются маленькими дисками в контексте статьи?` ---
**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\ **Post date:** [29.Ноябрь.2025 13:57:21 UTC](https://forum.samohosting.ru/t/tipy-diskov-v-zfs-prokachivaem-nash-raid-pri-pomoshhi-ssd/1363/5 "2025-11-29T13:57:21Z")
> [@Garrett](#): > > Я правильно понимаю, что 1 - 10 ТВ считаются маленькими дисками в контексте статьи? Это определение вышло из обсуждения дисков в ТГ канале, где обсуждались скорости дисков: надо смотреть характеристики конкретной модели, но в контексте, данной статьи подразумевается, что “мелкие” диски, например, на 3ТБ дают скорость чтения/записи порядка **120-160 МБ/сек** , что что заметно меньше SATA SSD, которые выдают 500-550 МБ/сек Если брать линейку Seagate Exos x18 18tb, то там уже линейные скорости могут достигать 270 МБ/сек, IOPS случайного чтения/записи порядка 170/550, что все равно не дотягивает до даже SATA SSD, но раза в 2 лучше, чем у 3TB дисков Т.е. большие и крутые жесткие диски за 40к рублей выдают лучше характеристики, чем диски за 4-6к рублей (хотя, они сейчас подорожали тоже до 6-10) Исходя из этого, эффект от SSD за 1 500р будет выше в сборке за 10к, чем в сборке за 100к, что логично, но при параллельной работе с массивом из множества клиентов даже жесткие диски за 40к будут тормозить и SSD будут иметь эффект ---
**Author:** ![kewgenia](https://forum.samohosting.ru/letter_avatar_proxy/v4/letter/k/c2a13f/32.png) [@kewgenia](https://forum.samohosting.ru/u/kewgenia)\ **Post date:** [02.Декабрь.2025 09:32:58 UTC](https://forum.samohosting.ru/t/tipy-diskov-v-zfs-prokachivaem-nash-raid-pri-pomoshhi-ssd/1363/6 "2025-12-02T09:32:58Z")
Подскажите как у вас устроено? Есть физический сервер PVE, на нем контейнер TrueNAS с пробросом дисков. Как это устроено при замене вышедшего из строя диска или замены на больший объём. Или всё таки это две разные машины? ---
**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\ **Post date:** [02.Декабрь.2025 11:17:22 UTC](https://forum.samohosting.ru/t/tipy-diskov-v-zfs-prokachivaem-nash-raid-pri-pomoshhi-ssd/1363/7 "2025-12-02T11:17:22Z")
Обсуждалось [тут](https://forum.samohosting.ru/t/nadyozhnost-probrosa-diska-v-truenas/1146) Если говорить про меня, то у меня физический сервер PVE, внутри него виртуалка с TrueNAS, в эту виртуалку проброшены 1. PCI-E → sata контроллер `hostpci0: 0000:01:00.0` при подключении к нему диска он сразу появляется в TrueNAS 2. Проброс дисков и разделов в качестве дисков `scsi1: /dev/disk/by-id/ata-P3-512_9S50814007018-part1,backup=0,serial=VDEV_DATA_1,size=230G` При подключении диска к хосту егонадо добавить в виртуалку командой вида `qm set 102 --scsi9 /dev/disk/by-id/ata-P3-512_9S50814006998,backup=0,serial=SERIAL_NUMBER` Соответственно, при замене диска или увеличении размера (а это делается путем подключения нового диска и замены старого на новый в интерфейсе TrueNAS надо либо просто воткнуть его в проброшенный PCI-E → SATA/SAS контроллер, это может быть HBA, либо физическое подключение и прокидывание в ВМ вызовом соответствующей команды > Дисклеймеры > > 1. Убедитесь, что диски, корзины, контроллеры поддерживает горячее подключение, в идеале подключать на выключенном TrueNAS. У меня M.2 контроллер нормально с этим живет, а вот USB → Sata при подключении дисков перезагружается, что приводит к возникновению ошибок работы с уже подключенными дисками > 2. Подключенный 2 способом диск должен быть в системе на момент старта ВМ, если диска не окажется, что PVE не сможет запустить TrueNAS и тогда надо будет руками удалить из конфига ВМ извлеченный диск ---
**Author:** ![Nialpo](https://forum.samohosting.ru/letter_avatar_proxy/v4/letter/n/90ced4/32.png) [@Nialpo](https://forum.samohosting.ru/u/Nialpo)\ **Post date:** [15.Январь.2026 03:06:39 UTC](https://forum.samohosting.ru/t/tipy-diskov-v-zfs-prokachivaem-nash-raid-pri-pomoshhi-ssd/1363/8 "2026-01-15T03:06:39Z")
Ссылка на детальное теоретическое описание ZFS, с дополнительными параметрами пулов и датасетов: [https://jro.io/truenas/openzfs/#tuning](https://jro.io/truenas/openzfs/#tuning) ---
**Author:** ![gda98](https://forum.samohosting.ru/letter_avatar_proxy/v4/letter/g/958977/32.png) [@gda98](https://forum.samohosting.ru/u/gda98)\ **Post date:** [28.Январь.2026 22:05:35 UTC](https://forum.samohosting.ru/t/tipy-diskov-v-zfs-prokachivaem-nash-raid-pri-pomoshhi-ssd/1363/9 "2026-01-28T22:05:35Z")
Что то у Вас ExosЫ отстойные, наверное SATA? Вот Exos X14 SAS 10TB. Два SAS в RAID 0 включаем, и SDD SATA улетает в помойку, как проигравший! ДА, конечно КЕШ в контроллере RAID включен, он для этого и предназначен, чтобы при линейной записи-чтении ушатывать SATA девайсы! ![SAS_10ТВ](https://forum.samohosting.ru/uploads/default/original/2X/2/29eccc8dfcadedd7076ca771c712e2cdb2d52aa6.png) ---
**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\ **Post date:** [29.Январь.2026 07:52:29 UTC](https://forum.samohosting.ru/t/tipy-diskov-v-zfs-prokachivaem-nash-raid-pri-pomoshhi-ssd/1363/10 "2026-01-29T07:52:29Z")
> [@gda98](#): > > Что то у Вас ExosЫ отстойные, наверное SATA? Вот Exos X14 SAS 10TB У меня не Exosы и даже не SAS, у меня SATA WD 3TB, вроде даже пометку делал, что эффект заметен в основном на дешевых дисках > [@gda98](#): > > Два SAS в RAID 0 включаем, и SDD SATA улетает в помойку, как проигравший! Мы тут говорим про ZFS и про надежность (чуть ли не треть статьи отведена на то, чтобы обезопасить данные) Вы же про аппаратный RAID контроллер, с которыми ZFS не работает (по крайней мене официально заявляет и отказывается от любых гарантий), так еще и в RAID0, который явно не про надежность, а про циферки в бенчмарках. > [@gda98](#): > > ДА, конечно КЕШ в контроллере RAID включен, он для этого и предназначен, чтобы при линейной записи-чтении ушатывать SATA девайсы! > [@gda98](#): > > SDD SATA улетает в помойку, как проигравший! Ну кстати, линейная скорость даже на больших блоках у Вас все равно ниже нормаьных SSD SATA, а про случайную запись мы сделали вид, что не видим значения А вообще обидно даже, я тут расписывал про iops, хранение различных типов данных на SSD, дедубликацию, синхронную и асинхронную запись и все это под различные сценарии использования (где будет работать, а где нет), а мне тут в лицо скриншот линейной скорости записи RAID0 SAS EXos ---
**Author:** ![wpbuild](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/wpbuild/32/2130_2.png) [@wpbuild](https://forum.samohosting.ru/u/wpbuild)\ **Post date:** [29.Январь.2026 13:06:25 UTC](https://forum.samohosting.ru/t/tipy-diskov-v-zfs-prokachivaem-nash-raid-pri-pomoshhi-ssd/1363/11 "2026-01-29T13:06:25Z")
Достал из помойки SSD SATA 6 лет уже работающий 24/7 посмотрел: ![2026-01-29_20-06-52](https://forum.samohosting.ru/uploads/default/original/2X/a/a1a594b5c259f718d19a3467a018edec987e493c.jpeg) Норм, пусть еще в помойке постоит… )))