Apacer NAS SSD: обзор SSD, созданного для использования в NAS

Apacer, известный производитель SSD с многолетней историей, выпустил линейку SSD, ориентированных непосредственно на NAS, сетевых хранилищ для дома и малого офиса. Типоразмеры M2 NVMe, M2 SATA, 2.5” SATA, объём до 2T, кратно увеличенная износоустойчивость. Потестим эти устройства и постараемся влезть им в потроха. Но сначала — о применимости SSD в NAS вообще.

Ария гречневой каши

Здравствуйте. Меня зовут Михаил Кувшинов, ники 2gusia и MikeMac, и самосборные NAS — моё давнее хобби. Я куратор ветки «NAS своими руками» на форуме ixbt, модератор русскоязычной секции официального форума xigmanas, веду в ЖЖ журнал 2gusia. Давным-давно, в 2013 г. публиковал на ixbt.com статью «NAS для дома своими руками» в двух частях — «холодное железо» и «программное обеспечение» которая, как ни странно, за столько лет частично сохранила полезность. Так что, надеюсь, мои сегодняшние мысли и впечатления о SSD будут интересны для владельцев NAS — прежде всего гиков-энтузиастов, но не только. Конструктивная критика приветствуется — и те, кто со мной сталкивался на сетевых просторах знают, что это не пустые слова.

Для чего в NAS SSD?

Сама идея использования SSD в NAS вызывает вопросы. Все же NAS — один из бастионов, до сих пор удерживаемых жесткими дисками. Потому, что скорости HDD в целом хватает, а цена за терабайт существенно ниже. Соответственно, потенциальные ниши для SSD там, где их преимущества значимы. Ниши пока не такие большие, но их нашлось немало. Сразу уточню, что речь далее пойдет о NAS для SOHO (буквально — малый офис, домашний офис) и домашнего использования.

Полная замена жесткого диска

All flash storage, полная замена HDD на SSD — это как раз большие корпоративные системы, которые мы обойдем вниманием. SSD в таких системах много и чаще всего используется формфактор U2. Шина PCI-e 3.0 здесь уже становится узким местом по скорости. А PCI-e 4.0 только-только входит в широкое употребление. Хотя появились и первые решения на PCI-e 5.0 В SOHO же полная замена HDD на SSD целесообразна скорее в специальном случае скромных требований по хранимому объему. Например, активная домашняя аудиотека вряд займет больше терабайта. Дороже — зато применение SSD позволит сделать NAS бесшумным и очень компактным — этакий микро NAS. Да любая, за исключением видео, информация — текст, код, фото, музыка — достаточно компактна для хранения на SSD NAS.

Компактный компьютер, одной из многих функций которого может быть микро NAS.

Скорее всего использоваться будет одиночный накопитель, без RAID массивов. Возможно и зеркало, но обычно большого смысла нет. Массивы с дублированием — это не про сохранность информации, это про доступность ее даже в случае отказа носителя. В SOHO обычно потери из-за простоя при восстановлении из бекапа ниже, чем стоимость дублирующего накопителя — будь то SSD или HDD.

Как и для любой сколь-нибудь ценной информации настоятельно рекомендован бекап. Для таких объемов подойдут простейшие варианты вроде внешнего жесткого диска.

Когда статья была уже почти написана, вышел пост на форуме камрада MethroGnome

Цитата: коробка от Synology DS620slim + 16 Гб ОЗУ + 6 SSD по 4 Тб (Samsung 860 EVO). Все это работает под FreeBSD 13.0 с 3-мя ZFS-пулами, бюджет этого NAS — 306000 р

10Gbps сеть

Следующий, и наиболее очевидный вариант — это использование 10 Gbit сети. Кто-то скажет — слишком дорого, в SOHO такого не бывает. Для себя лично я ответил на этот вопрос точно также. Но, судя по общению в нашей профильной ветке, настоящие гики 10 гигабит дома используют сплошь и рядом. Строят локальные peer-to-peer мини-сети, пользуясь тем фактом, что на вторичном рынке сетевые карты можно найти достаточно бюджетные, в отличие от коммутаторов. Понятно, что в таком NAS не только HDD, но и SATA SSD станет узким местом.

Системный диск

Основное применение SSD в настольном компьютере или ноутбуке, но в NAS требования к системному диску минимальны. Часто используется просто USB флешка. Мало того, например в стандартной конфигурации XigmaNAS (ранее nas4free), который я и использую, флешка хранит лишь образ системы. При включении создается небольшой системный диск в памяти, образ разворачивается на него, конфигурируется в соответствии с пользовательскими настройками — и система загружается с него. Очень важно простейшее восстановление. Если что-то пошло не так, например пользователь, начитавшись не тех инструкций, испортил что-то на системном диске — достаточно перезагрузить NAS. Если физически умерла системная флешка — нужно загрузить стандартный образ, нарезать его на новую флешку, стартовать с него и скормить системе единственный XML файл конфигурации.

Понятно, в таком варианте требования к загрузочной флешке минимальны, и SSD здесь явно избыточен. Хотя многие другие варианты NAS все же используют загрузочный носитель традиционно. SSD им тоже по большому счету не обязателен — но SSD крошеного объема сегодня дешевле подобного HDD. Такой системный накопитель, в отличие от флешки, имеет большой смысл зеркалить, так как восстановление работоспособности при аппаратном сбое затянется. А вот выделять под систему кусочек большого SSD считается неудачной практикой. Данные и систему в NAS принято разделять.

Антикварный индустриальный SSD на 16 Gb из запасов автора. Брал пару как раз для экспериментов под зеркало для системы с Root on ZFS.

Кеширование

Одно из самых частых применение SSD в NAS. Например, при использовании файловой системы ZFS (доступной под Linux, FreeBSD, форками Solaris), вся оперативная память именно под такой кеш и отдается. Понятно. кроме занятой непосредственно ОС. Этот кэш в терминах ZFS называется ARC (adaptive replacement cache). Поэтому, кстати, и известно, что ZFS любит много оперативной памяти. В ARC попадают считываемые с дисков данные (и метаданные — служебная информация, необходимая для работы с данными, вроде контрольных сумм). При многократном к ним обращении на чтение и возникает выигрыш. Объемы оперативной памяти относительно размеров дисков невелики, наиболее редко используемые данные вытесняются из ARC. Но это поведение можно изменить, добавив кеш второго уровня, т.н. L2ARC — обычно на SSD. Тогда данные, вытесненные из ARC, попадают в L2ARC, откуда могут быть считаны существенно быстрее, чем с дисков.

Полезность L2ARC очень сильно зависит от рода нагрузки на NAS. Если это типичный домашний сценарий, с просмотром фильмов, фоток и прослушиванием музыки, то проку от кеширования не будет. Данные просто редко используются повторно. Более того, применение L2ARC даже принесет небольшой вред, так как на его обслуживание будет затрачена оперативная память (порядка 2-3% от размера L2ARC, точная цифра зависит от ряда параметров). Если это офис, в котором несколько пользователей постоянно имеют доступ к одному и тому же набору данных, при этом этот набор не влезает в оперативную память NAS — то эффект может быть значительным.

Одним из специфических применений L2ARC является его использование в системах с включенной ZFS дедупликацией. Последняя реализована в реальном времени и на уровне блоков. Цена такого решения высока — если таблица дедупликации не помещается в оперативную память — система встает буквально колом. Поэтому ZFS дедупликацию настоятельно не рекомендуют использовать всем, кроме профессионалов, до деталей разбирающихся в проблеме. Использование L2ARC облегчает ситуацию, но настоятельная рекомендация остается в силе.

Кеширующее устройство L2ARC работает только на чтение, но не на запись, поэтому не нуждается в зеркалировании или бекапе — все данные есть на жестких дисках. При аппаратной проблеме на SSD данные с дисков и будут считаны. Традиционно при перезагрузке системы данные в L2ARC теряются и затем постепенно, в течение нескольких дней, вновь накапливаются. Одной из важных новинок недавно выпущенной версии OpenZFS 2.0 стала возможность сохранить содержимое перезагрузке.

Производители коробочных NAS в последние годы предлагают фирменные программные решения для кеширования на SSD, работающие поверх файловой системы. Возможно кэширование как (подобно ZFS L2ARC) только на чтение, так и на чтение и запись. Важное различие — при работе на запись SSD нуждается в зеркалировании, иначе его сбой может стать фатальным. Естественно, производители предлагают в более продвинутых своих NAS и возможность подключения SSD. SATA SSD подключаются стандартным образом (занимая столь дорогие в коробочных NAS места под диски данных). Ряд моделей имеет M2 слоты для подключения NVME и M2 SATA SSD. Доступно также подключение в PCI-E слот через специальные карты-переходники.

Ускорение синхронной записи в ZFS

ZFS использует специальный механизм для синхронной записи данных — то есть такой записи, когда приложение требует подтверждения о физическом завершении записи и только затем работает дальше. В большинстве случаев, вроде копирования файлов, такой необходимости нет, исключения — работа с базами данных и подобные сценарии, когда потеря малого куска информации может угробить всё. Не вдаваясь в детали, синхронную запись в ZFS можно ускорить, применив SLOG (Separate Intent Log) устройство. Оно должно иметь собственную батарейку, то есть переживать перезагрузку и чудовищный ресурс на перезапись. Зато необходимый размер невелик — несколько гигабайт. Фактически SLOG устройство работает только на запись. В него непрерывно осуществляется запись, а считывание происходит только в случае аварии. Обычные, даже корпоративного уровня SSD, исчерпают ресурс на запись слишком быстро. На практике для SLOG могут применяться память NVRAM и, с некоторыми ограничениями, корпоративного уровня SCL SSD и (недавно снятые с производства) Intel Optane.

Виртуальные машины

NAS, что у гика дома, что в малом офисе, почти всегда больше чем NAS. Достаточно часто это еще и сервер виртуализации. Виртуальные системные диски виртуальных машин очень много выиграют от переноса с HDD на SSD. Тут все просто и выигрыш очень похож на выигрыш от замены на SSD системного диска в ноутбуке или десктопе. Можно сказать, что использование SSD в этом случае настоятельно рекомендовано. Переносить ли на SSD диски данных виртуальных машин, если такие есть — зависит от вида нагрузки.

Миллионы мелких файлов

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

nas4free: plexpass# ls -l -R plexdata | grep ^- | wc -l

95594

Это картинки и текстовые файлы, как легко видеть, меньше 300 К на файл в среднем. Если бы разработчик использовал базу данных — проблемы бы не было. А так только чтение столь фрагментированной информации занимает огромное время. Естественно желание перенести подобные данные на SSD с малым кластером и сильно ускорить работу Plex. Отмечу, что в случае ZFS с мелкими файлами возникает дополнительный оверхед. Механизма типа NTFS MFT не предусмотрено — каждый файл хранится в отдельной записи. Длина записи переменная, но не менее сектора диска, 4K в наше время. Плюс на каждый файл минимум один сектор метаданных, еще минимум 4K. (Упрощаю, есть хранение особо мелких файлов прямо в метаданных, но не будем уходить в дебри.)

Для такого типа данных может иметь смысл использовать не дисковые пулы, а SSD. Отзывчивость того же Plex явно улучшается, если его папку plexdata с описаниями медиа расположить на SSD. Зеркало может и будет полезно в таком случае — но обычно не слишком оправдано. Часто подобная информация не является невосстановимой, как в случае Plex и ее в крайнем случае ее можно наработать заново. Бекап я все же делаю — места занимает немного.

Метаданные и файлы менее заданного размера

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

NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT

somepool 175T 163T 11.7T — - 3% 93% 3.86x ONLINE -

raidz2 175T 163T 11.3T — - 3% 93.5% — ONLINE

special — - — - — - — - -

mirror 508G 166G 342G — - 53% 32.6% — ONLINE

Видно, что здесь на special vdev метаданными занято примерно 0.1% от объема данных на дисковой части пула, то есть очень и очень немного. Поэтому разработчики предложили опцию хранения на таком vdev также и мелких файлов, причем граница размера задается администратором. Если как special vdev использовать зеркало из SSD с малым, 512 байт, сектором — то получается интересное автоматическое win-win распределение пространства в соответствии с потребностями. Большие файлы хранятся на HDD, хорошо приспособленных для последовательного чтения и записи. Сильно фрагментированная информация — метаданные и мелкие файлы — на SSD, обеспечивающих высокие характеристики при случайном доступе.

Отвлекаясь чуть в сторону. Автору кажется (но это частное мнение), что дальнейшее развитие в этом направлении могло бы примирить ZFS с черепичными, ака SMR дисками. В которых данные можно считывать произвольно, а записывать — только достаточно большими зонами. Просто файловой системе нужно дать доступ к тому, пишется ли информация в CMR зону или в SMR ленту. Тогда она сможет расположить данные разного типа оптимально.

Apacer NAS SSD

Поводом к написанию этой статьи стал выпуск компанией Apacer линии SSD специально ориентированных для использования в NAS. Они отличаются от бытовых 5-летней гарантией и примерно втрое более высокой заявленной износоустойчивостью. TBW чуть больше 2000 объемов накопителя — например для терабайтного SSD — 2 петабайта. Известно, что цифры TBW — это оценка снизу, то, за что производитель отвечает гарантийными обязательствами. В реальности износоустойчивость может быть и много больше. А может и не быть — как повезет. Поэтому трехкратное различие имеет значение. Жаль, его быстро проверить невозможно.

Исполнение — три из современных четырех распространенных вариантов. Серии PPSS25, PPSS80 и PP3480 — соответственно 2.5” SATA 6 Гб/с, M2 SATA и M2 NVMe (PCI-E 3.0 x4). При этом NVMe исполнение почему-то называется PCI-E, хотя установить их в PCI-E слот удастся только с переходником. Что мы чуть позже и сделаем.

Варианта U2 исполнения нет. Впрочем, U2 вряд ли актуально для SOHO рынка.

Я решил, что тестировать все три варианта нет особого смысла. Будет достаточно двух M2 Вариантов. Все скоростные характеристики у 3.5” SATA варианта будут идентичны M2 SATA. А по нагреву если и будет какое-то отличие, то на M2 все вылезет рельефнее. Конечно, для работы в некоторых режимах нужен не один SSD, а зеркало. И производитель предлагал пару одинаковых NVMe. Но я решил, что разные будет посмотреть интереснее.

Характеристики

Все SSD предлагаются в вариантах 128ГБ/256ГБ/512ГБ/1TБ/2TБ

• (2ТБ — кроме M2 SATA исполнения)
• ŸMTBF: 2,000,000 часов
• ŸПоддерживают системы S.M.A.R.T. и TRIM
• TBW, как сказано выше — около 2000 на объем.

Скорости у двух SATA вариантов, естественно, совпадают

• ŸСкорость последовательного чтения: до 550 Мб/с
• ŸСкорость последовательной записи: до 500 Мб/с
• 4K скорость случайной записи (в IOPS): 84,000 / 86,000 IOPS

У NVME варианта

• ŸСкорость последовательного чтения: до 2,500 Мб/с
• ŸСкорость последовательной записи: до 2,100 Мб/с
• Ÿ4K скорость случайной записи (в IOPS): 215,000 / 390,000 IOPS

Пояснения производителя

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

Стандартная формула расчета TBW = (capacity x WLE (wear leveling) x P/E cycles) / WAF (write amplification) x 1024

Т.е для увеличения износостойкости надо либо увеличить числитель, либо уменьшить знаменатель. Компания Apacer сделала и то, и другое

1) Циклы P/E: при производстве TLC-памяти, циклы P/E в ней распределены по-разному: от 300 до 3000К. Это напоминает ситуацию с покупкой мяса: разные части туши ценятся по-разному и продаются по разным ценам. Усредненное и официальное значение TLC составляет 1,5 К, хотя между собой производители понимают разницу и закупают TLC-память по разным ценам. Так, для производства USB берутся «копыта», или «уши», с 300-500К, для индустриальной части – куски пожирнее, от 1.5К и выше

Для SSD в системах NAS Apacer закупает TLC-память лучшего качества, с 3К циклом, что заверено как производителем Phison, так и проверено на наших тестах.

2) Улучшенная firmware, прошивка. Алгоритм работы новой прошивки специально разработан для целей NAS. В отличие от edge computing, в NAS идет запись large and sequential data, а не small and random, а потому и подход к прошивке должен быть другой. Обновленный алгоритм значительно уменьшает WAF, вследствие чего цикл жизни увеличивается

В общем, износостойкость достигается и за счет харда, который вывозит такое количество циклов; и за счет софт-части, которая создана с целью минимизировать внутреннюю работу диска

Теперь IMHO. То, что флеш память бывает разных грейдов — медицинский факт. Они действительно стоят очень по-разному и действительно крупным производителям SSD доступны разные грейды памяти. Так что, думаю, про использование высокого грейда флеш памяти — правда. Apacer, как крупный производитель SSD, получает память разных грейдов. Довольно естественно, что высший он ставит в премиальные продукты, на которые дает повышенные спеки и гарантии по износоустойчивости.

Насчет специальной прошивки — у меня возникли сомнения. Что прошивка специальная — запросто возможно. И написать ее стоит денег. А вот загрузить уже ее готовую в SSD стоит столько же, сколько любую другую. И если есть очень хорошая прошивка, снижающая износ, естественно грузить ее не только в премиальные SSD, а во все. Можно возразить, конечно, что это совсем специальная прошивка, которая работает хорошо только с премиального грейда памятью. В принципе, исключить этого нельзя, хоть и странно. Поэтому я попросил уточнение и его дали

Цитата инженера поддержки "If we use small random write F/W for NAS SSD, it will cause waste your NAND flash blocks, which means not efficient F/W design. So we customize F/W for NAS read/write behavior to get low WA and better TBW" — в моем переводе: «Если мы используем прошивку, оптимизированную для записи малых случайных блоков для NAS SSD, это приведет к не оптимальному использованию флэш-блоков NAND памяти, то есть к неэффективной конструкции прошивки. Поэтому мы настраиваем прошивку для сценария чтения / записи, характерного для NAS, чтобы получить низкий износ и лучше TBW»

Компоненты, M2 SATA

Контроллер ps3111-s11-13. Даташит Из него, кcтати, видно, что предельный размер для M2 — терабайт. Видимо, поэтому 2T версии есть только для 3.5” SATA и NVMe, но не для M2 SATA.

Память

Гуглинг показывает, что TA7BG65AWV — это 96 слойная TLC память Toshiba. Но, понятно, производитель не дает гарантии того, что так будет всегда.

Компоненты, NVMe

Контроллер ps5013-e13-31 Даташит

Память та же

Тесты

Тестировать у меня получилось в три этапа. Во-первых нашлись две USB 3.1 Gen2 коробочки для M2 SSD — SATA и NVMe одного производителя. Во-вторых, в моем ноутбуке есть место для второго M2 SSD. Правда, только в NVMe варианте. Ну и, конечно, установим оба SSD в NAS и попробуем сравнить между собой и с HDD. В качестве NAS у меня компьютер общего назначения под управление Xigmanas (в девичестве Nas4free). Это довольно популярная сборка на базе FreeBSD 12.2-RELEASE-p3. Файловая система ZFS (но еще исконный, без свежих плюшек. На OpenZFS 2.0 FreeBSD переходит не спеша.)

Тесты в USB гробиках

Известно, что из SSD и USB корпуса для нее можно получить очень быструю и емкую флешку. Например для Windows 2 Go (все своё ношу с собой). У меня нашлось два внешне идентичных корпуса для M2 SSD — один для SATA, другой для NVMe. Оба USB 3.1. Gen 2, подключение через TypeC. Вряд ли, конечно, покупатель обозреваемых SSD будет сразу использовать эти SSD именно так. Но со временем такова судьба многих из них — объемы растут, старые куда-то надо девать.

А еще я решил, что 10 Gbps USB 3.1 Gen2 — подойдет как дешевая модель 10 Gbps NAS, которого у меня нет. В обоих случаях — ограничение — со стороны 10 Гигабитного интерфейса.

Производитель — достаточно известная китайская компания Ugreen. Имеет неплохую репутацию, по моему опыту к качеству относится серьезно. Внутри

SATA — VID_174C&PID_55AA — ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge

NVMe — VID_174C&PID_2362 -ASM2362 USB to PCI Express NVMe SSD bridge

HDD Tune Pro

С этого теста начнем потому, что пишет только на неразмеченный накопитель. На входе оба SSD были девственно чистыми. Это не честно. Поэтому я оба сначала прогнал на запись с дефолтными настройками — размер блока 64K — запись такая ровненькая получилась — как у всех в обзорах. :) А затем изменил размер блока на 256К — и прогнал еще раз тест.

Чтение, SATA, затем NVMe. Потом они же на запись.

CDM

Любимая в народе утилита с мелким таким недостатком — показывает с поправкой на погоду на Марсе. Тестовый размер 1 и 32 гигабайта.

ATTO

Это софтина мне лично как-то более понятные результаты выдает.

По скорости та же значительная разница на последовательных операциях. IOPSы выглядят похоже. Но если приглядеться — NVMe обгоняет SATA и здесь — и заметно.

Предположу, что на 10Gbps NAS будет что-то в этом роде — разница между SATA и NVMe будет не только по последовательному чтению (что на практике не так и важно), но и по IOPS.

Кстати, выше я приводил ссылки на даташиты контроллеров. Так вот, из них можно видеть, что PS3111-S11, который SATA, дает 4K Random Read и Write 82K IOPS. А

ps5013-e13-31, который NVMe — гораздо больше, 230K IOPS Read 400K IOPS Write. И мы видим небольшую часть этой разницы сохранившейся даже в тестах через USB мосты.

Прочее

TRIM работает даже на обоих вариантах USB гробиков.

Нагрев незначительный, в том числе и у NVMe (у NVMe контроллера заявлено среднее энергопотребление 3.7 Вт, против 2.1 у SATA). Сколько ест по спекам память — не нашел.

SMART — читается даже через USB мосты если софт достаточно новый. Так что SSD точно SMART отдает.

Тесты на ноутбуке

Мой ноутбук — Dell Vostro 7590, вариант на Intel Core i5-9300H 9-го поколения, 8Gb RAM, NVIDIA GeForce GTX 1050. Комп мой рабочий, относительно новый, покупался в весной 2020.

На ноуте три слота M.2. M.2 2230 под WLAN карту отпадает, M.2 2280/2230/2242 универсальный занят системным диском и я не стал его вытаскивать, третий M.2 2280 поддерживает только NVMe, но не SATA. Поэтому я ограничился в ноуте тестированием только NVMe варианта в третьем слоте и не вижу в этом значительной проблемы. В SATA варианте мы упремся в ограничения шины.

HD Tune Pro

Гонял полные тесты, по всему объему пару раз — картина примерно одинаковая. В принципе, получилось чуть меньше чем по спекам. Проверил — слот PCIe Gen 3 x4 NVMe, до 32 Гбит/с. Но все же думаю, дело в моем ноутбуке. Процессор не особо мощный. Да и вообще вряд ли он заточен на максимальное раскрытие потенциала накопителей. На практическое использование ноута не повлияет.

CDM

Зато на Марсе погода — красота, благолепие и легкий, ласкающий бриз :)

ATTO

Ни 215 ни, тем более, 390 указанный в спеках IOPS я тут не вижу. Но по прежнему отношу это на ограничения своего ноутбука.

Если серьезно — видим, что случайную запись и чтение в огромной степени зарезал в прошлом тесте USB мост.

NAS

Установка

Комп под NAS у меня достаточно древний (Intel Pentium G2120 @ 3.10GHz, ASUSTeK P8H77-M PRO, 16 Gb RAM, FreeBSD 12.2-RELEASE-p3, xigmanas 12.2.0.4 revision 8044) и NVMe слота в нем нет. Но есть процессорный PCI-E 3.0. Его и буду использовать.

Купил за $4.5 на Али вот такой переходник

Это PCI-e x4 карта на два M2 слота. Один она просто соединяет с PCI-e шиной — и туда мы вставляем NVM-e SSD. А вторая использует PCI-e только для питания. А данные ходят через SATA порт. Что-то подобное есть и у производителей коробочных NAS. Но, боюсь, слегка дороже.

Обнаружение

На свежей FreeBSD NAS (использую Xigmanas 12.2.0.4 — Ornithopter, revision 8044) оба SSD обнаружились без проблем.

nas4free: ~# uname -a

FreeBSD nas4free.local 12.2-RELEASE-p3 FreeBSD 12.2-RELEASE-p3 #0 r369193M: Mon Feb 1 09:57:18 CET 2021 root@dev_zoon01@xigmanas.com:/usr/obj/xigmanas/usr/src/amd64.amd64/sys/XIGMANAS-amd64 amd64

Привожу фрагменты выхлопа dmesg

nas4free: ~# dmesg | grep nvd
nvd0: <PP3480-R 1TB> NVMe namespace
nvd0: 976762MB (2000409264 512 byte sectors)
nvd0: <PP3480-R 1TB> NVMe namespace
nvd0: 976762MB (2000409264 512 byte sectors)

Посмотрим что еще про него известно системе

nas4free: ~# nvmecontrol devlist
nvme0: PP3480-R 1TB
nvme0ns1 (976762MB)
nas4free: ~# nvmecontrol identify nvme0ns1
Size: 2000409264 blocks
Capacity: 2000409264 blocks
Utilization: 2000409264 blocks
Thin Provisioning: Not Supported
Number of LBA Formats: 2
Current LBA Format: LBA Format #00
Data Protection Caps: Not Supported
Data Protection Settings: Not Enabled
Multi-Path I/O Capabilities: Not Supported
Reservation Capabilities: Not Supported
Format Progress Indicator: Not Supported
Deallocate Logical Block: Read Not Reported, Write Zero
Optimal I/O Boundary: 0 blocks
NVM Capacity: 1024209543168 bytes
Globally Unique Identifier: 00000000000000000000000000000000
IEEE EUI64: 6479a73c80300015
LBA Format #00: Data Size: 512 Metadata Size: 0 Performance: Better
LBA Format #01: Data Size: 4096 Metadata Size: 0 Performance: Best

Видно, что SSD может работать и в режиме 512 байтного сектора и, быстрее, на 4K. Но IMHO мне гораздо полезнее для ZFS метаданных 512, даже ценой некоторой потери производительности.

SATA SSD стал у нас ada0 (da0-da7 — HDD на SAS HBA контроллере, da8 — системная USB флешка, ada1 и ada2 — пара HDD на набортных SATA)

nas4free: ~# camcontrol devlist
<ATA ST4000DM000-1F21 CC52> at scbus0 target 4 lun 0 (pass0,da0)
<ATA ST4000DM000-1CD1 CC43> at scbus0 target 5 lun 0 (pass1,da1)
<ATA ST4000DM000-1F21 CC52> at scbus0 target 6 lun 0 (pass2,da2)
<ATA ST4000DM000-1F21 CC52> at scbus0 target 7 lun 0 (pass3,da3)
<ATA ST4000DM000-1F21 CC51> at scbus0 target 8 lun 0 (pass4,da4)
<ATA ST4000DM000-1F21 CC52> at scbus0 target 9 lun 0 (pass5,da5)
<ATA ST4000DM000-1F21 CC52> at scbus0 target 11 lun 0 (pass6,da6)
<ATA ST4000VX000-2AG1 CV11> at scbus0 target 15 lun 0 (pass7,da7)
<PPSS80-R 1TB AP613PE0> at scbus1 target 0 lun 0 (pass8,ada0)
<SAMSUNG HD204UI 1AQ10001> at scbus2 target 0 lun 0 (pass9,ada1)
<SAMSUNG HD204UI 1AQ10001> at scbus3 target 0 lun 0 (pass10,ada2)
<Kingston DT 101 II 1.00> at scbus4 target 0 lun 0 (pass11,da8)

Смотрим что про него думает система.

nas4free: ~# dmesg | grep ada0
ada0 at ahcich2 bus 0 scbus1 target 0 lun 0
ada0: <PPSS80-R 1TB AP613PE0> ACS-4 ATA SATA 3.x device
ada0: Serial Number 832033400187
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 976762MB (2000409264 512 byte sectors)
ses0: ada0 in 'Slot 02', SATA Slot: scbus1 target 0

УПС :( SATA 3 устройство работает в SATA 2 режиме. Надо смотреть… Так и есть — я воткнул провод в синий SATA порт, а оказалось на моей матери синий — это SATA 2. SATA 3 — белый. Придется переткнуть.

После перетыкания M2 SSD в SATA 3 порт он остался ada0. Смотрим детали

nas4free: ~# dmesg | grep ada0
ses0: ada0 in 'Slot 00', SATA Slot: scbus1 target 0
ada0 at ahcich0 bus 0 scbus1 target 0 lun 0
ada0: <PPSS80-R 1TB AP613PE0> ACS-4 ATA SATA 3.x device
ada0: Serial Number 832033400187
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 976762MB (2000409264 512 byte sectors)

Все нормально, теперь подключение SATA3 (Прим Внимательный читатель может спросить — а почему написано 600.000MB/s, а не 6GB/s? Ведь в байте 8 бит, а тут отношение 10? Дело в том, что в SATA протоколе на 8 информационных бит приходится 2 контрольных. И чтобы передать байт, передается 10 бит, а не 8. Так что полезная полоса пропускания при 6GB/s составляет как раз 600.000MB/s. Но маркетологи любят писать не полезные цифры, а красивые. Сравните двумя строками ниже с тем, что “терабайтный” накопитель имеет полный объем лишь 976762MB. Те же милые хитрости. И это еще Apacer выдал с запасом — даже не 2 миллиарда секторов, как мог бы, а 409264 “лишних”)

Создаем ZFS пулы

Одновременно с парой SSD я добавил пустой HDD на 2 терабайта — чтобы сравнивать с ним SSD в максимально равных условиях. Диск, правда, у меня SATA 2 — но практической разницы в случае HDD между SATA 2 и SATA 3 нет.

Эту главу можно при ознакомлении пропустить. Но по опыту, потом людям не раз понадобятся копировать какие-то команды — так что привожу их. Люди инстаграма все равно досюда не дочитали :)

SATA SSD

Во-первых, я хочу пул с сектором на 512 байт

nas4free: ~# sysctl vfs.zfs.min_auto_ashift=9
vfs.zfs.min_auto_ashift: 12 -> 9

Создаю однодисковый пул на этом устройстве на GPT метке в соответствии с серийным номером устройства. Потому, что добавление-удаление устройств в FreeBSD нумерацию устройств тасует, а имена GPT меток стабильны.

gpart create -s GPT /dev/ada0
gpart add -t freebsd-zfs -l S_832033400187 -a 1M /dev/ada0
zpool create -m /mnt/SSD_SATA SSD_SATA /dev/gpt/S_832033400187

NVME

То же самое делаю на NVMe устройстве

gpart create -s GPT /dev/nvd0
gpart add -t freebsd-zfs -l N_c80301015 -a 1M /dev/nvd0
zpool create -m /mnt/NVME NVME /dev/gpt/N_c80301015

возвращаю размер сектора для zfs в прежнее состояние

sysctl vfs.zfs.min_auto_ashift=12
vfs.zfs.min_auto_ashift: 9 -> 12

HDD

И создаю пул на жестком диске

zpool create -m /mnt/HDD HDD /dev/gpt/D_S2H7J1DB210089

Измерения

Есть у меня ранее упомянутая папка с огромным числом мелких файлов. Это метаданные Plex. Я скопировал ее на оба SSD и на тестовый HDD

nas4free: ~# du -sh /mnt/NVME/plexdata/
28G /mnt/NVME/plexdata/
nas4free: ~# ls -l -R /mnt/NVME/plexdata/ | grep ^- | wc -l
95594

Видно — 28 Гигабайт и без малого 100500 файлов.

Теперь перезагрузим NAS и измерим время чения этой папки на каждом из трех устройств. Для этого поищем произвольный текст во всех файлах

nas4free: /mnt# time grep -r Any-text /mnt/NVME/plexdata/
15.968u 21.562s 1:26.09 43.5% 91+171k 670927+0io 0pf+0w
nas4free: /mnt# time grep -r Any-text /mnt/SSD_SATA/plexdata/
16.439u 20.878s 2:05.84 29.6% 89+169k 670949+0io 0pf+0w
nas4free: /mnt# time grep -r Any-text /mnt/HDD/plexdata/
30.018u 34.483s 12:31.12 8.5% 91+173k 671173+0io 0pf+0w

Видно, что на NVMe операция заняла 1 мин 26 сек, на SATA SSD — 2 мин 6 сек — на треть больше, а на HDD — 12 мин 31 сек — больше. Если перевести в скорости — 325, 222 и 23 Мб/c

Давайте теперь повторим эксперимент на таком же объеме данных, но единым файлом. Для этого отправляем все файлы в единый архив, без компрессии.

nas4free: NVME# tar -cf plexdata.tar plexdata

Затем для чистоты эксперимента перезагружаем машину — и повторяем тест

nas4free: ~# time grep -r Any-text /mnt/NVME/plexdata.tar
14.152u 10.345s 0:33.62 72.8% 90+170k 219722+0io 0pf+0w
nas4free: ~# time grep -r Any-text /mnt/SSD_SATA/plexdata.tar
13.783u 7.232s 1:07.83 30.9% 92+173k 210961+0io 0pf+0w
nas4free: ~# time grep -r Any-text /mnt/HDD/plexdata.tar
22.839u 9.869s 4:15.09 12.8% 90+171k 210836+0io 0pf+0w

Втрое быстрее. Разница между HDD и NVMe примерно сохранилась, SATA SSD стал относительно хуже — он обгонял жесткий диск вшестеро на мелких файлах, на одном большом — лишь вчетверо. От NVMe отставал на треть — теперь вдвое.

Далее я попытался провести собственно сетевой тест на этой папке. Копирование средствами Windows с сетевого диска начинается длительной, на много-много минут, процедурой подсчета файлов. А затем начинается собственно копирование. С крайне огорчительной скоростью

Что интересно, и с HDD и с SSD копирование занимает практически одинаковое время. А специально проверил на маленькой папке на 1000 файлов и 74 мегабайта в сумме. Объяснить это могу тем, что ZFS использует упреждающее чтение. То есть если файловая система получает указание считать определенный блок, она считывает и его и сколько-то вперед. А в нашем случае папки я писал на пустые диски, то есть мелкие файлы лежат там по порядку. И упреждающее считывание с ними справляется.

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

По уму и на практике при такой задаче (скопировать 100500 мелких файлов) нужно создавть архив на источнике, передавать его и, при необходимости, разархивировать.

На десерт

А в самом конце я вытащил SSD из NAS, вставил в свой старый комп, списался с известным в узких кругах специалистом под ником vlo и воспользовался его утилитами, читающим потроха запоминающих устройств, которые Вадим любезно выложил в публичный доступ

Вижу на SATA версии 96-слойную память Toshiba, контроллер Phison PS3111, Dram 32MB, PE Cycle Limit: 3000 и MaxBBPerPlane: 74

При этом пороге в 74 в реальности от 8 до 27 плохих блоков на банк, все исконные, ни одного нового, появившегося в процессе моей недолгой эксплуатации. На NVMe та же память Toshiba, исконных плохих блоков побольше — но тоже в пределах. Вроде все нормально. Заодно показаны SMART-ы

Отчет по SATA версии

Отчет по NVMe версии

SMART и логи NVMe версии

Итого

У Apacer получились интересные SSD в трех типоразмерах, до 2T. Премиальной, но не запредельной стоимости. В современных OS определяются из коробки — не только Windows 10, но и FreeBSD. В Windows 7 мне пришлось поставить руками драйвер. Если для ваших задач SSD нужны в NAS — подходящий вариант. Но вполне могут работать и ноутбуке и в десктопе.