Обзор USB to Ethernet адаптера Ugreen CM275, работающего на скорости до 2.5Гбит/c
- Цена: ~2500р с промиком в конце обзора
- Перейти в магазин
Всем привет. Сегодня у меня на обзоре адаптер, для организации скоростной сети Ethernet через USB.
Сетевые контроллеры со скоростью 2.5Гбит/c, уже пару лет как устанавливаются в материнские платы (в основном в модели среднего ценового сегмента и выше) вместо 1Гбит/c решений, и сети со скоростями 2.5Гбит/c постепенно идут в массы.
Появилась и у меня как раз такая материнская плата (MSI Z590-A PRO), с контроллером Intel I225-V. Да это не 10Гбит/c, но всё же в 2.5 раза быстрее 1Гбит/c решений.
Вступление
Достаточно продолжительное время у меня в голове крутится план создания быстрого домашнего NAS, используя возможности ФС ZFS (точнее OpenZFS) +ISCSI (есть ещё оптимизированные под NAS решения с ZFS на борту), и собственно для этих нужд, мною рассматриваются два варианта организации сети, со скоростью 2.5Гбит/c и 10Гбит/c, со своими плюсами и минусами, в обзоре порассуждаю над 2.5 Гбит/c вариантом сети.
Сеть 2.5Гбит/c
Плюсы:
1. Распространённость и более высокая доступность (новые материнские платы стоимостью от 8000р обычно идут с сетевухой именно на 2.5Гбит/c, можно легко докупить USB адаптер или PCI-E x1 карту (хватит даже PCI-E Gen2) на 2.5Гбит/c при необходимости, что бы старый ПК (с поддержкой USB 3.0 или PCI-E Gen2) заставить работать на этой же скорости сетевого подключения).
2. Низкое энергопотребление данного решения.
3. Можно использовать «стандартную» 4-х парную витую пару категории 5E.
Минусы:
Скорость сильно меньше 1ГБ/c (реальная скорость около 300МБ/c), т.е этот вариант больше подходит для NAS, построенном чисто на базе жёстких дисков, а современные NVMe SSD запросто могут отдавать и гораздо большие скорости, поэтому смысл таких сетей несколько размывается в моём понимании, но это быстрая сеть «для всех».
10Гбит/c
Плюсы
1.Собственно скорость в районе 1ГБ/c.
Минусы
1. Нужно тянуть более дорогой (но не смертельно) и помехозащищённый кабель 6 категории. В моём случае надо разбирать/передвигать шкафы что бы кинуть в плинтуса новый кабель, чем заниматься не хочется.
2. Высокое энергопотребление. В режиме 24/7, даже в простое, этот вариант должен кушать сильно больше чем 2.5Гбит вариант.
3. Стоимость такого решения выше. На тао правда есть варианты двухпортовых сетевых карт Intel X540 в районе 10$ за штучку, но хз как оно взлетит, будут ли норм работать дрова под свежую Ubuntu.
4. Нужен слот X8 (либо использовать более распространённый в десктопах X16 или пилить так же достаточно редкий X4, так как карта работает в режиме PCI-E Gen2, поэтому ей надо минимум 2 линии для одного порта). Придётся как на NAS так и на клиенте занимать слот под такую карту.
5. Так как адаптеры серверные, по идее они рассчитаны на обдув радиатора, придётся обдувать их, что не всегда удобно организовать и обслуживать.
Касаемо прайсов на таобао, то они достаточно вкусные, но это без учёта доставки по Китаю и затем доставки в РФ из Китая.
Что есть из железок на тао, из того что может пригодиться для домашней хранилки, и почём?
Касаемо тао, для домашнего NAS там можно прикупить много «ништяков», вот пример с ценами с сайта посредника yoybuy.com, где они пишут и цену в $, из того что мне удалось найти, из интересного.
Здесь у меня отложено в корзину две X540 примерно за 15$ с доставкой по Китаю, адаптер под два NVMe SSD в одном PCI-E слоту x8 за 6.27$ (PCI-E слотов много не бывает, особенно быстрых, есть и более дорогие варианты на 4 NVMe SSD под слот x16, но мать должна поддерживать такой режим с «делением» линий разъёма между двумя устройствами), дешёвая DDR3 Reg память, материнка для более простого NAS, где в нужном количестве PCI-E слоты, достаточно производительный и самое главное экономичный процессор, который даже в режиме 24*7 не скушает много энергии, и запитать такую МП и NAS целиком, по идее можно от мощного Gan зарядника.
Есть там и недорогие PCI-E Ethernet адаптеры на 2.5Гбит/c.
Сейчас выбираю что заказать в первую очередь: кроссовки + б/у видеокарту или же диски+ сетевые карты+ переходник под NVMe, всё надо). Оба «набора» выходят не дёшево, но такие сейчас времена, юань нынче продают по 12+ рублей, а $ за 90+ рублей. Доставка будет тоже дорогая, но её я планирую чутка сбить купонами от посредника.
Ну и по поводу железа есть ещё конечно вариант взять что то с авито, но вот с треми же дисками там цены что то не очень гуманные, но с другой стороны в каком состоянии придёт диск с тао вопрос, но велика вероятность что всё же живым. В общем буду ещё считать и думать насчёт рисков, принимая окончательное решение.
Про свою задумку и муки выбора я кратко рассказал (возможно напишу отдельную статью с большим объёмом полезной информации), а теперь вернёмся к теме обзора и проведём тестирование самого адаптера.
Распаковка
Поставляется адаптер в фирменной коробке.
На обороте упаковки есть кое какая информация о продукте.
Сам адаптер и микро инструкция к нему:
Порт Ethernet
Тестирование
Для тестов я взял свой тестовый патчкордик, собственноручно обжатый пару лет назад, длиной около 10м. Категория кабеля 5E, 4 пары.
Первым делом смотрю в диспетчере устройств тестового ПК наличие сетевого адаптера от Ugreen, через некоторое время Windows 10 сама ставит драйвер (есть доступ в интернет с ПК) и адаптер появляется в списке. А так, при подключении адаптера появляется виртуальный CD-ROM с дровами от Ugreen, и драйвер можно поставить от туда.
Адаптер гордо определяется как игровой, со скоростью 2.5Гбит/c.
По ID оборудования видно что он построен на контроллере Realtek RTL8156. Кстати, как я выяснил, на сайте уже был обзор данного адаптера с разбором от tirarex, кому интересно предлагаю ознакомиться: ссылка
В начале, я решил проверить какая скорость соединения поднимется в связке с древним ноутбуком DELL D630, примерно 2007 г.в, где встроенная сетевушка на 1Гбит/c. Выставил принудительно на Ugreen CM275, в настройках, скорость в 1Гбит/c.
Ноут подключился только на 10Мбит/c и то соединение как то нехотя устанавливалось, чуть ли не пару минут. Возможно дело в том что адаптер в ноутбуке древний, драйвер я не уверен что самый свежий под него и полноценный, ну и в настройках Ugreen CM275 есть опция что соединение сперва поднимается на 10МБит/c (как я понял), возможно это и сыграло роль, дальше я не стал разбираться с настройками, дабы не тратить время (думаю по итогу подружил бы их на гигабите).
Затем, для проверки с сайта Realtek скачал драйвер, поставил его, но результат не изменился.
Кстати, первый компьютер (Pentium 4 530J) у меня появился в далёком 2005 году, и уже тогда там был сетевой интерфейс умеющий 1Гбит/c, без малого 20 лет прошло.
После уже начал соединять Ugreen CM275 и Intel I225-V.
Кстати, в отзывах на МП встречались такие что была не совместимость данной встройки с роутером, или что то такое. Думаю в настройках можно было бы всё «разрулить», и проблема была скорее всего больше на стороне роутера, где не были учтены в полной мере какие то расширенные особенности стандарта, но это лишь мои догадки, у меня с данной встройкой проблем не возникло, при том что драйвер стоит автоматически установленный ОС (intel уже заблокировал все ресурсы для РФ, только через proxy или VPN заграничный качать. Даже ark не так давно заблокировали).
В итоге, я соединил два сетевых адаптера между собой, и получил скорость соединения 2.5Гбит/c.
Далее, начал тестировать скорость в Iperf с «дефолтными» настройками, и получал итог выше гигабита, но меньше 2-х.
В итоге, выкрутил на обоих адаптерах размер фрэйма около 9КБ (9014 байт).
Скорость сразу выросла до значений выше 2Гбит/c, не дотягивая до 2.5Гбит/c.
Дополнительно, поднял ещё размеры входящего и исходящего буфера на Ugreen CM275. По умолчанию там значение вроде бы было 16 (не понятна единица измерения).
Максимально буфер можно выставить до 256, но при если выставить значения 128/256, подключение устанавливается, но Iperf почему то отказывается работать.
В итоге оставил значение на 64, так с ним всё прекрасно работает, с явным увеличением скорости.
На Intel -овской карте, как я понял настройка буфера общая, и значение там 1024, его трогать не стал.
После всех настроек, переходим к итоговым скришотам из Iperf.
Iperf стандартный режим (отправка с Intel I225-V на Ugreen CM275, скриншоты с ПК где используется Intel I225-V).
При этом, скорость стабильная. Вот итоги 10- минутного теста, за который по сети передался 171ГБ данных:
На данном скриншоте всё то же самое что и на первом, но только тест идёт в 10 потоков, и как видим на скорость это не влияет, и это нормально для Ethernet, а вот при тестировании WI-FI адаптера был бы прирост. Скорости по сути максимальные.
Iperf режим реверса (отправка с Ugreen CM275 на Intel I225-V, скриншоты с ПК где используется Intel I225-V):
При этом Windows пишет что приём идёт на скорости 2.4Гбит/c, а iperf рапортует нам о том что скорость всего 2.27Гбит/c.
Не, так дело не пойдёт, опять меняю размер кадра (Jumbo Frame), на этот раз понижая его до значения 4088 байт, для обоих контроллеров.
Смотрю скорости после изменения размера кадра:
Как видим, скорости в обычном режиме, и в реверсном (ключ -R сверху скриншота), почти сравнялись, и очень близки к заветным 2.5Гбит/c.
Во время простоя, и в моменты передачи и приёма на скорости 2.5Гбит/c, я замерил потребление адаптера, дабы не быть голословным что кушают такие адаптеры не много, и получил что потребление всегда одинаково, не зависимо от того идёт ли сейчас интенсивная передача, или просто поднят линк.
ISCSI тесты
Я установил Ubuntu 22.04.2-desktop-amd64, на SATA SSD DEXP C100 (128ГБ) и настроил там ISCSI target, создав «виртуальный» диск на 8ГБ с помощью dd всё на том же SATA SSD DEXP C100, который и отдавался по сети.
Под Windows, в рамках SLC кэша (а он там динамический и весьма большой) данный SSD показывает достаточно приличные скорости в CDM:
При гиговом тесте всё однозначно попадёт в SLC кэш, даже с учётом того что сама Ubuntu заняла под себя некоторый объём.
При этом, драйвер для Ugreen CM275, а точнее для RTL8156 ставить не пришлось, Ubuntu 22.04.2 (а возможно и некоторые более ранние версии) уже умеет с ним работать из коробки.
Ради интереса, я сравнил скорости в CDM, при тесте через ISCSI, т.е. по сети, используя при этом разные сетевухи на ПК с Ubuntu. Там кроме подключенной Ugreen CM275, есть и гигабитная встройка, то же Realtek (даже не смотрел наименование), и мне было интересно сравнить скорость ISCSI диска по мелким блокам с размером 4К, ибо в случае с Ugreen CM275, должна была быть дополнительная задержка за счёт вложения Ethernet по USB, не считая собственно задержек самого ISCSI +Ethernet.
В случае со встроенной сетевой картой на гигабит, задержки тоже будут, но меньше, так как контроллер там висит на PCI-E, и будут лишь по сути видны задержки самого протокола ISCSI ну и сети Ethernet.
В WIndows 10 (ISCSI Initiator) было настроено подключение к компьютеру с Ubuntu, и началась работа с сетевым диском отдаваемым Ubuntu как с обычным диском. Отформатировал его через диспетчер дисков в NTFS, и начал тестирование скоростей.
Тест с сетевым адаптером на 1Гбит/c (установлен на ПК с Ubuntu. На ПК с Win10 I225-V ).
Тест с сетевым адаптером на 2.5Гбит/c (Ugreen CM275, установлен на ПК с Ubuntu. На ПК с Win10 I225-V).
Для передачи просто больших файлов вроде видео или фото на сетевое хранилище, скорость по 4К блокам по сути не важна, и как видим такие файлы будут примерно в 2.5 раза быстрее передаваться в обе стороны чем в случае с гигабитным подключением.
Для массива RAID1 постороенного на HDD, такие скорости будут даже с ощутимым запасом, в том числе небольшой запас будет и по 4К блокам. Если есть необходимость максимально раскрыть потенциал SSD накопителей, например при хранении образа ВМ на сетевом диске, то тут уже надо использовать сетевую карту работающую напрямую через шину PCI-E.
Когда я увидел что скорость работы с мелкими блоками сильно разнится из-за задержек, решил ещё посмотреть что в Ubuntu с настройками MTU (а то вдруг чего изменится при корректировке), и как выяснилось драйвер там не поддерживает MTU выше 1500 байт, т.е. размер кадра стандартный, ни о каких MTU размерностью 4088 или 9000 байт речи не идёт.
Плюс когда тестировал под виндой, особо не проверял пинги в обе стороны, да и винда несколько округляет значения, но в случае с Linux, при сравнении пингов в связках гигабитная встройка-> I225-V и Ugreen CM275 -> I225-V, в последнем случае пинги оказались выше.
Кстати, что интересно, видимо из-за видиокарты (она у меня древняя и чуть живая) на скриншотах наблюдаются небольшие артефакты.
Подведу итоги по Ugreen CM275
Плюсы
1. Низкое энергопотребление и не сильный нагрев.
2. Стабильность и соответствие заявленной скорости.
Минусы
1. Нет индикации активности (не сильно критично).
2. Цена девайса (должна упасть).
Адаптер работает стабильно, заявленные 2.5 Гбит/c выдаются.
UPD: магазин дал промокод UCM275 (5$ скидки, около 500р, работает до 15 августа).
Сетевые контроллеры со скоростью 2.5Гбит/c, уже пару лет как устанавливаются в материнские платы (в основном в модели среднего ценового сегмента и выше) вместо 1Гбит/c решений, и сети со скоростями 2.5Гбит/c постепенно идут в массы.
Появилась и у меня как раз такая материнская плата (MSI Z590-A PRO), с контроллером Intel I225-V. Да это не 10Гбит/c, но всё же в 2.5 раза быстрее 1Гбит/c решений.
Вступление
Достаточно продолжительное время у меня в голове крутится план создания быстрого домашнего NAS, используя возможности ФС ZFS (точнее OpenZFS) +ISCSI (есть ещё оптимизированные под NAS решения с ZFS на борту), и собственно для этих нужд, мною рассматриваются два варианта организации сети, со скоростью 2.5Гбит/c и 10Гбит/c, со своими плюсами и минусами, в обзоре порассуждаю над 2.5 Гбит/c вариантом сети.
Сеть 2.5Гбит/c
Плюсы:
1. Распространённость и более высокая доступность (новые материнские платы стоимостью от 8000р обычно идут с сетевухой именно на 2.5Гбит/c, можно легко докупить USB адаптер или PCI-E x1 карту (хватит даже PCI-E Gen2) на 2.5Гбит/c при необходимости, что бы старый ПК (с поддержкой USB 3.0 или PCI-E Gen2) заставить работать на этой же скорости сетевого подключения).
2. Низкое энергопотребление данного решения.
3. Можно использовать «стандартную» 4-х парную витую пару категории 5E.
Минусы:
Скорость сильно меньше 1ГБ/c (реальная скорость около 300МБ/c), т.е этот вариант больше подходит для NAS, построенном чисто на базе жёстких дисков, а современные NVMe SSD запросто могут отдавать и гораздо большие скорости, поэтому смысл таких сетей несколько размывается в моём понимании, но это быстрая сеть «для всех».
Зачем мне большая скорость локальной сети? Много букв.
В частности, я тестировал Ubuntu с ФС ZFS на борту, используя возможности данной ФС по кэшированию данных в RAM (ARC) и на быстрый SSD накопитель (L2ARC).
Серверная ОЗУ сейчас стоит не дорого, можно при желании хоть на 64-128ГБ не так уж дорого собрать кэш на DDR3 ECC Reg памяти, но логичнее использовать относительно небольшой кэш в RAM, и всё остальное держать в кэше на быстром NVMe накопителе, объёмом 500-1000ГБ.
Кэш этот работает только на чтение, все данные лежат на основном носителе (медленном). В моём случае хочу использовать программное зеркало (RAID1), на двух HDD объёмом 4ТБ или около того.
Плюс ZFS умеет сжимать данные, искать дубликаты, проверять контрольные суммы держа данные в сохранности.
В своё время, лет 6 назад, я занимался перебором всех возможных вариантов хэширования по алгоритму CRC32 (точнее это делал ПК), и забивал результаты в Mysql БД, которая хранилась на накопителе с ФС ZFS, где с помощью включения сжатия в ZFS, удалось объём таблицы с данными уменьшить почти в 2 раза (изначально не влезала она), и оно в итоге влезло на SSD объёмом 128ГБ, т.е. для ряда задач, а точнее сжимаемых данных, сжатие крайне эффективный инструмент, но правда оно будет дополнительно нагружать процессор.
Пока я ещё не определился что же всё-таки брать по дискам SAS или SATA (выбираю из б/у на тао), здесь у тех и у тех есть как плюсы так и минусы, почти как у вариантов с сетью. Но это уже другая история, сейчас весь процесс застопорился в основном на этом, сети это больше вторичное, так как для начала можно и на скорости 2.5 Гбит/c всё обкатать.
По поводу записи, есть в ZFS вариант с синхронной записью с использованием внешнего устройства журнала (нужен быстрый NVMe накопитель), этот вариант надёжный и более быстрый чем хранение журнала на том же накопителе где и файлы (режим по умолчанию), но я пока нормально его не протестировал, ввиду того что кучу времени убил пока гонял тесты на ВМ под управлением Wmware Workstation, где была развёрнута ОС Ubuntu, а в ВМ диски и их скорость живут своей жизнью, Wmware пытается там что то колдовать сама с буферизацией на диски, искажая результаты замеров (буферизацию накопителей в основной ОС я отключал).
Отключить буферизацию со стороны Wmware Workstation, у меня не получилось, и я не стал сильно зацикливаться по этому поводу, а просто поставил ОС на свободную сборку на базе E5-2673V3. Ость поставлена на ext4, и далее уже на втором накопителе создан пул ZFS. А так, Ubuntu можно сейчас и установить на ZFS прямо из коробки, и кстати сжатие там по умолчанию будет включено.
Есть и более опасный вариант асинхронной записи, когда запись сначала буферизируется в RAM (можно настроить объём и ещё кучу параметров), и параллельно, скидывается на основной накопитель по мере его возможностей (в моём случае это был медленный SATA SSD с QLC памятью, где я знал объём SLC кэша, и писал гораздо больше данных чем его размер).
По итогу, большие файлы сгенерированные утилитой dd, записывались со скоростью почти 2ГБ/c (при том что SSD может только пару десятков гигов писать со скорость не более 500МБ/c), параллельно шла запись как в RAM так и на накопитель. Такая скорость получилась при генерации рандомных данных, и плюс сжатие в ФС было отключено. В случае с буферизацией в ФС ext4, таких скоростей записи не достичь.
Это опасный вариант записи, ведь если заглючит само ядро ФС, или отрубят свет, то данные пропадут не дойдя до накопителя, при том что приложение которое их сгенерировало, будет считать что запись прошла успешно и данные лежат на накопителе. Может заглючить и память, но в случае с серверной памятью которая умеет ECC, вариант менее реалистичный чем два варианта выше. Если обеспечить резервирование питания (UPS, самопальная подача 12В на МП с авто переключением), то можно в приципе использовать этот вариант, и утилизировать все 10Гбит/c сети в лёгкую.
Ряд приложений, например СУБД, по умолчанию всегда пишут данные в синхронном режиме (с подтверждением записи от ОС), но в ФС ZFS можно принудительно выставить опцию что бы всё писалось в асинхронном режиме.
Вообще, изначальная моя цель получить что то типо хорошего SATA SSD, но по сети, при этом с высокой надёжностью данных, сочетая быстродействие твердотельных накопителей с интерфейсом NVMe, и плюсы НЖМД накопителей (HDD) в плане безопасного, долговременного хранения данных. Т.е взяв всё лучшее от обоих типов накопителей, руководствуясь принципом НБН -Надёжно, быстро, не дорого.
Минусы SSD — стекание заряда, непредсказуемость поведения в традиционном RAID1 массиве, где противоречивость данных на дисках массива никак не проверяется (по крайней мере в программной зеркале собранном средствами Windows 10).
У меня на канале есть видео как я в WinHex подменял данные на дисках членах массива RAID1, на виртуальной машине. ОС всегда читала данные с первого диска из двух, даже если данные там по каким то причинам были изменены пока она не работала, и отличались от второго диска, где данные были валидными. Проверка данных там по сути не является целью, цель — если откажет один из накопителей, сохранить данные.
Возможен ещё вариант с миксом данных с обоих накопителей, его я не тестировал так как это уже другой уровень массива, и проблема там останется та же.
Не факт конечно что из-за стекания заряда данные прочитаются в искажённом виде, и контроллер SSD это заблаговременно не пресечёт, но такая вероятность по идее есть, как по идее и с массивом на HDD. Да и два быстрых SSD держать в массиве такое себе.
Как по мне, интересно иметь универсальное хранилище большого объёма, где часть востребованных данных будет в кэше, а оставшаяся часть будет спокойно храниться на надёжном хранилище (вместе с той частью что есть ещё и в кэше), и при этом доступ к хранилищу будет с любого ПК подключенного к домашней сети.
Т.е. тем самым использовав плюсы обоих типов накопителей: скорость твердотельников и способность HDD к долговременному хранению данных, плюс всё ещё более низкую стоимость хранения для HDD.
Единственное, ещё понадобится либо быстрый свитч (дорого но удобно), либо вариант проксирования трафика от роутера с гигабитными портами (к нему подключены интернет провайдер и другие устройства в локальной сети, например смартфоны подключенные к роутеру по WI-FI), до целевого ПК с 2.5Гбит/c адаптером, который будет напрямую связан с NAS имеющим тот же порт, и второй гигабитный порт уже для связи с роутером, т.е получится некий шлюз.
Последний вариант выглядит в моём сознании как то так:
Что то похожее на Ubuntu я делал, поэтому думаю что это вполне реально, но поживём увидим.
Серверная ОЗУ сейчас стоит не дорого, можно при желании хоть на 64-128ГБ не так уж дорого собрать кэш на DDR3 ECC Reg памяти, но логичнее использовать относительно небольшой кэш в RAM, и всё остальное держать в кэше на быстром NVMe накопителе, объёмом 500-1000ГБ.
Кэш этот работает только на чтение, все данные лежат на основном носителе (медленном). В моём случае хочу использовать программное зеркало (RAID1), на двух HDD объёмом 4ТБ или около того.
Плюс ZFS умеет сжимать данные, искать дубликаты, проверять контрольные суммы держа данные в сохранности.
В своё время, лет 6 назад, я занимался перебором всех возможных вариантов хэширования по алгоритму CRC32 (точнее это делал ПК), и забивал результаты в Mysql БД, которая хранилась на накопителе с ФС ZFS, где с помощью включения сжатия в ZFS, удалось объём таблицы с данными уменьшить почти в 2 раза (изначально не влезала она), и оно в итоге влезло на SSD объёмом 128ГБ, т.е. для ряда задач, а точнее сжимаемых данных, сжатие крайне эффективный инструмент, но правда оно будет дополнительно нагружать процессор.
Пока я ещё не определился что же всё-таки брать по дискам SAS или SATA (выбираю из б/у на тао), здесь у тех и у тех есть как плюсы так и минусы, почти как у вариантов с сетью. Но это уже другая история, сейчас весь процесс застопорился в основном на этом, сети это больше вторичное, так как для начала можно и на скорости 2.5 Гбит/c всё обкатать.
По поводу записи, есть в ZFS вариант с синхронной записью с использованием внешнего устройства журнала (нужен быстрый NVMe накопитель), этот вариант надёжный и более быстрый чем хранение журнала на том же накопителе где и файлы (режим по умолчанию), но я пока нормально его не протестировал, ввиду того что кучу времени убил пока гонял тесты на ВМ под управлением Wmware Workstation, где была развёрнута ОС Ubuntu, а в ВМ диски и их скорость живут своей жизнью, Wmware пытается там что то колдовать сама с буферизацией на диски, искажая результаты замеров (буферизацию накопителей в основной ОС я отключал).
Отключить буферизацию со стороны Wmware Workstation, у меня не получилось, и я не стал сильно зацикливаться по этому поводу, а просто поставил ОС на свободную сборку на базе E5-2673V3. Ость поставлена на ext4, и далее уже на втором накопителе создан пул ZFS. А так, Ubuntu можно сейчас и установить на ZFS прямо из коробки, и кстати сжатие там по умолчанию будет включено.
Есть и более опасный вариант асинхронной записи, когда запись сначала буферизируется в RAM (можно настроить объём и ещё кучу параметров), и параллельно, скидывается на основной накопитель по мере его возможностей (в моём случае это был медленный SATA SSD с QLC памятью, где я знал объём SLC кэша, и писал гораздо больше данных чем его размер).
По итогу, большие файлы сгенерированные утилитой dd, записывались со скоростью почти 2ГБ/c (при том что SSD может только пару десятков гигов писать со скорость не более 500МБ/c), параллельно шла запись как в RAM так и на накопитель. Такая скорость получилась при генерации рандомных данных, и плюс сжатие в ФС было отключено. В случае с буферизацией в ФС ext4, таких скоростей записи не достичь.
Это опасный вариант записи, ведь если заглючит само ядро ФС, или отрубят свет, то данные пропадут не дойдя до накопителя, при том что приложение которое их сгенерировало, будет считать что запись прошла успешно и данные лежат на накопителе. Может заглючить и память, но в случае с серверной памятью которая умеет ECC, вариант менее реалистичный чем два варианта выше. Если обеспечить резервирование питания (UPS, самопальная подача 12В на МП с авто переключением), то можно в приципе использовать этот вариант, и утилизировать все 10Гбит/c сети в лёгкую.
Ряд приложений, например СУБД, по умолчанию всегда пишут данные в синхронном режиме (с подтверждением записи от ОС), но в ФС ZFS можно принудительно выставить опцию что бы всё писалось в асинхронном режиме.
Вообще, изначальная моя цель получить что то типо хорошего SATA SSD, но по сети, при этом с высокой надёжностью данных, сочетая быстродействие твердотельных накопителей с интерфейсом NVMe, и плюсы НЖМД накопителей (HDD) в плане безопасного, долговременного хранения данных. Т.е взяв всё лучшее от обоих типов накопителей, руководствуясь принципом НБН -Надёжно, быстро, не дорого.
Минусы SSD — стекание заряда, непредсказуемость поведения в традиционном RAID1 массиве, где противоречивость данных на дисках массива никак не проверяется (по крайней мере в программной зеркале собранном средствами Windows 10).
У меня на канале есть видео как я в WinHex подменял данные на дисках членах массива RAID1, на виртуальной машине. ОС всегда читала данные с первого диска из двух, даже если данные там по каким то причинам были изменены пока она не работала, и отличались от второго диска, где данные были валидными. Проверка данных там по сути не является целью, цель — если откажет один из накопителей, сохранить данные.
Возможен ещё вариант с миксом данных с обоих накопителей, его я не тестировал так как это уже другой уровень массива, и проблема там останется та же.
Не факт конечно что из-за стекания заряда данные прочитаются в искажённом виде, и контроллер SSD это заблаговременно не пресечёт, но такая вероятность по идее есть, как по идее и с массивом на HDD. Да и два быстрых SSD держать в массиве такое себе.
Видео с тестами
Как по мне, интересно иметь универсальное хранилище большого объёма, где часть востребованных данных будет в кэше, а оставшаяся часть будет спокойно храниться на надёжном хранилище (вместе с той частью что есть ещё и в кэше), и при этом доступ к хранилищу будет с любого ПК подключенного к домашней сети.
Т.е. тем самым использовав плюсы обоих типов накопителей: скорость твердотельников и способность HDD к долговременному хранению данных, плюс всё ещё более низкую стоимость хранения для HDD.
Единственное, ещё понадобится либо быстрый свитч (дорого но удобно), либо вариант проксирования трафика от роутера с гигабитными портами (к нему подключены интернет провайдер и другие устройства в локальной сети, например смартфоны подключенные к роутеру по WI-FI), до целевого ПК с 2.5Гбит/c адаптером, который будет напрямую связан с NAS имеющим тот же порт, и второй гигабитный порт уже для связи с роутером, т.е получится некий шлюз.
Последний вариант выглядит в моём сознании как то так:
Что то похожее на Ubuntu я делал, поэтому думаю что это вполне реально, но поживём увидим.10Гбит/c
Плюсы
1.Собственно скорость в районе 1ГБ/c.
Минусы
1. Нужно тянуть более дорогой (но не смертельно) и помехозащищённый кабель 6 категории. В моём случае надо разбирать/передвигать шкафы что бы кинуть в плинтуса новый кабель, чем заниматься не хочется.
2. Высокое энергопотребление. В режиме 24/7, даже в простое, этот вариант должен кушать сильно больше чем 2.5Гбит вариант.
3. Стоимость такого решения выше. На тао правда есть варианты двухпортовых сетевых карт Intel X540 в районе 10$ за штучку, но хз как оно взлетит, будут ли норм работать дрова под свежую Ubuntu.
4. Нужен слот X8 (либо использовать более распространённый в десктопах X16 или пилить так же достаточно редкий X4, так как карта работает в режиме PCI-E Gen2, поэтому ей надо минимум 2 линии для одного порта). Придётся как на NAS так и на клиенте занимать слот под такую карту.
5. Так как адаптеры серверные, по идее они рассчитаны на обдув радиатора, придётся обдувать их, что не всегда удобно организовать и обслуживать.
Касаемо прайсов на таобао, то они достаточно вкусные, но это без учёта доставки по Китаю и затем доставки в РФ из Китая.
Что есть из железок на тао, из того что может пригодиться для домашней хранилки, и почём?
Касаемо тао, для домашнего NAS там можно прикупить много «ништяков», вот пример с ценами с сайта посредника yoybuy.com, где они пишут и цену в $, из того что мне удалось найти, из интересного.
Здесь у меня отложено в корзину две X540 примерно за 15$ с доставкой по Китаю, адаптер под два NVMe SSD в одном PCI-E слоту x8 за 6.27$ (PCI-E слотов много не бывает, особенно быстрых, есть и более дорогие варианты на 4 NVMe SSD под слот x16, но мать должна поддерживать такой режим с «делением» линий разъёма между двумя устройствами), дешёвая DDR3 Reg память, материнка для более простого NAS, где в нужном количестве PCI-E слоты, достаточно производительный и самое главное экономичный процессор, который даже в режиме 24*7 не скушает много энергии, и запитать такую МП и NAS целиком, по идее можно от мощного Gan зарядника.
Скриншоты с ценами
Есть там и недорогие PCI-E Ethernet адаптеры на 2.5Гбит/c.
Сейчас выбираю что заказать в первую очередь: кроссовки + б/у видеокарту или же диски+ сетевые карты+ переходник под NVMe, всё надо). Оба «набора» выходят не дёшево, но такие сейчас времена, юань нынче продают по 12+ рублей, а $ за 90+ рублей. Доставка будет тоже дорогая, но её я планирую чутка сбить купонами от посредника.
Ну и по поводу железа есть ещё конечно вариант взять что то с авито, но вот с треми же дисками там цены что то не очень гуманные, но с другой стороны в каком состоянии придёт диск с тао вопрос, но велика вероятность что всё же живым. В общем буду ещё считать и думать насчёт рисков, принимая окончательное решение.
Про свою задумку и муки выбора я кратко рассказал (возможно напишу отдельную статью с большим объёмом полезной информации), а теперь вернёмся к теме обзора и проведём тестирование самого адаптера.
Распаковка
Поставляется адаптер в фирменной коробке.
На обороте упаковки есть кое какая информация о продукте.Сам адаптер и микро инструкция к нему:
Порт Ethernet
Тестирование
Для тестов я взял свой тестовый патчкордик, собственноручно обжатый пару лет назад, длиной около 10м. Категория кабеля 5E, 4 пары.
Первым делом смотрю в диспетчере устройств тестового ПК наличие сетевого адаптера от Ugreen, через некоторое время Windows 10 сама ставит драйвер (есть доступ в интернет с ПК) и адаптер появляется в списке. А так, при подключении адаптера появляется виртуальный CD-ROM с дровами от Ugreen, и драйвер можно поставить от туда.
Адаптер гордо определяется как игровой, со скоростью 2.5Гбит/c.
По ID оборудования видно что он построен на контроллере Realtek RTL8156. Кстати, как я выяснил, на сайте уже был обзор данного адаптера с разбором от tirarex, кому интересно предлагаю ознакомиться: ссылкаВ начале, я решил проверить какая скорость соединения поднимется в связке с древним ноутбуком DELL D630, примерно 2007 г.в, где встроенная сетевушка на 1Гбит/c. Выставил принудительно на Ugreen CM275, в настройках, скорость в 1Гбит/c.
Ноут подключился только на 10Мбит/c и то соединение как то нехотя устанавливалось, чуть ли не пару минут. Возможно дело в том что адаптер в ноутбуке древний, драйвер я не уверен что самый свежий под него и полноценный, ну и в настройках Ugreen CM275 есть опция что соединение сперва поднимается на 10МБит/c (как я понял), возможно это и сыграло роль, дальше я не стал разбираться с настройками, дабы не тратить время (думаю по итогу подружил бы их на гигабите).
Затем, для проверки с сайта Realtek скачал драйвер, поставил его, но результат не изменился. Кстати, первый компьютер (Pentium 4 530J) у меня появился в далёком 2005 году, и уже тогда там был сетевой интерфейс умеющий 1Гбит/c, без малого 20 лет прошло.
После уже начал соединять Ugreen CM275 и Intel I225-V.
Кстати, в отзывах на МП встречались такие что была не совместимость данной встройки с роутером, или что то такое. Думаю в настройках можно было бы всё «разрулить», и проблема была скорее всего больше на стороне роутера, где не были учтены в полной мере какие то расширенные особенности стандарта, но это лишь мои догадки, у меня с данной встройкой проблем не возникло, при том что драйвер стоит автоматически установленный ОС (intel уже заблокировал все ресурсы для РФ, только через proxy или VPN заграничный качать. Даже ark не так давно заблокировали).В итоге, я соединил два сетевых адаптера между собой, и получил скорость соединения 2.5Гбит/c.
Далее, начал тестировать скорость в Iperf с «дефолтными» настройками, и получал итог выше гигабита, но меньше 2-х.
В итоге, выкрутил на обоих адаптерах размер фрэйма около 9КБ (9014 байт).9014 байт
Скорость сразу выросла до значений выше 2Гбит/c, не дотягивая до 2.5Гбит/c.
Дополнительно, поднял ещё размеры входящего и исходящего буфера на Ugreen CM275. По умолчанию там значение вроде бы было 16 (не понятна единица измерения). Максимально буфер можно выставить до 256, но при если выставить значения 128/256, подключение устанавливается, но Iperf почему то отказывается работать.
128
В итоге оставил значение на 64, так с ним всё прекрасно работает, с явным увеличением скорости.
На Intel -овской карте, как я понял настройка буфера общая, и значение там 1024, его трогать не стал.
После всех настроек, переходим к итоговым скришотам из Iperf.
Iperf стандартный режим (отправка с Intel I225-V на Ugreen CM275, скриншоты с ПК где используется Intel I225-V).
При этом, скорость стабильная. Вот итоги 10- минутного теста, за который по сети передался 171ГБ данных:
На данном скриншоте всё то же самое что и на первом, но только тест идёт в 10 потоков, и как видим на скорость это не влияет, и это нормально для Ethernet, а вот при тестировании WI-FI адаптера был бы прирост. Скорости по сути максимальные.
Iperf режим реверса (отправка с Ugreen CM275 на Intel I225-V, скриншоты с ПК где используется Intel I225-V):
При этом Windows пишет что приём идёт на скорости 2.4Гбит/c, а iperf рапортует нам о том что скорость всего 2.27Гбит/c.
Не, так дело не пойдёт, опять меняю размер кадра (Jumbo Frame), на этот раз понижая его до значения 4088 байт, для обоих контроллеров.
4088 байт
Смотрю скорости после изменения размера кадра:
Как видим, скорости в обычном режиме, и в реверсном (ключ -R сверху скриншота), почти сравнялись, и очень близки к заветным 2.5Гбит/c.
Во время простоя, и в моменты передачи и приёма на скорости 2.5Гбит/c, я замерил потребление адаптера, дабы не быть голословным что кушают такие адаптеры не много, и получил что потребление всегда одинаково, не зависимо от того идёт ли сейчас интенсивная передача, или просто поднят линк.
ISCSI тесты
Я установил Ubuntu 22.04.2-desktop-amd64, на SATA SSD DEXP C100 (128ГБ) и настроил там ISCSI target, создав «виртуальный» диск на 8ГБ с помощью dd всё на том же SATA SSD DEXP C100, который и отдавался по сети.
Под Windows, в рамках SLC кэша (а он там динамический и весьма большой) данный SSD показывает достаточно приличные скорости в CDM:
При гиговом тесте всё однозначно попадёт в SLC кэш, даже с учётом того что сама Ubuntu заняла под себя некоторый объём.При этом, драйвер для Ugreen CM275, а точнее для RTL8156 ставить не пришлось, Ubuntu 22.04.2 (а возможно и некоторые более ранние версии) уже умеет с ним работать из коробки.
Ради интереса, я сравнил скорости в CDM, при тесте через ISCSI, т.е. по сети, используя при этом разные сетевухи на ПК с Ubuntu. Там кроме подключенной Ugreen CM275, есть и гигабитная встройка, то же Realtek (даже не смотрел наименование), и мне было интересно сравнить скорость ISCSI диска по мелким блокам с размером 4К, ибо в случае с Ugreen CM275, должна была быть дополнительная задержка за счёт вложения Ethernet по USB, не считая собственно задержек самого ISCSI +Ethernet.
В случае со встроенной сетевой картой на гигабит, задержки тоже будут, но меньше, так как контроллер там висит на PCI-E, и будут лишь по сути видны задержки самого протокола ISCSI ну и сети Ethernet.
В WIndows 10 (ISCSI Initiator) было настроено подключение к компьютеру с Ubuntu, и началась работа с сетевым диском отдаваемым Ubuntu как с обычным диском. Отформатировал его через диспетчер дисков в NTFS, и начал тестирование скоростей.
Тест с сетевым адаптером на 1Гбит/c (установлен на ПК с Ubuntu. На ПК с Win10 I225-V ).
Тест с сетевым адаптером на 2.5Гбит/c (Ugreen CM275, установлен на ПК с Ubuntu. На ПК с Win10 I225-V).Для передачи просто больших файлов вроде видео или фото на сетевое хранилище, скорость по 4К блокам по сути не важна, и как видим такие файлы будут примерно в 2.5 раза быстрее передаваться в обе стороны чем в случае с гигабитным подключением. Для массива RAID1 постороенного на HDD, такие скорости будут даже с ощутимым запасом, в том числе небольшой запас будет и по 4К блокам. Если есть необходимость максимально раскрыть потенциал SSD накопителей, например при хранении образа ВМ на сетевом диске, то тут уже надо использовать сетевую карту работающую напрямую через шину PCI-E.
Когда я увидел что скорость работы с мелкими блоками сильно разнится из-за задержек, решил ещё посмотреть что в Ubuntu с настройками MTU (а то вдруг чего изменится при корректировке), и как выяснилось драйвер там не поддерживает MTU выше 1500 байт, т.е. размер кадра стандартный, ни о каких MTU размерностью 4088 или 9000 байт речи не идёт.
Плюс когда тестировал под виндой, особо не проверял пинги в обе стороны, да и винда несколько округляет значения, но в случае с Linux, при сравнении пингов в связках гигабитная встройка-> I225-V и Ugreen CM275 -> I225-V, в последнем случае пинги оказались выше.Пинги из Ubuntu
Кстати, что интересно, видимо из-за видиокарты (она у меня древняя и чуть живая) на скриншотах наблюдаются небольшие артефакты.Подведу итоги по Ugreen CM275
Плюсы
1. Низкое энергопотребление и не сильный нагрев.
2. Стабильность и соответствие заявленной скорости.
Минусы
1. Нет индикации активности (не сильно критично).
2. Цена девайса (должна упасть).
Адаптер работает стабильно, заявленные 2.5 Гбит/c выдаются.
UPD: магазин дал промокод UCM275 (5$ скидки, около 500р, работает до 15 августа).
Самые обсуждаемые обзоры
| +54 |
2352
104
|
| +47 |
2693
62
|
| +17 |
1384
30
|
| +48 |
1659
34
|
https://aliexpress.ru/item/item/1005003432672849.html
Месяц назад был по 600, не удержался, купил. Работает нормально, построен на том же Realtek RTL8156.
Это намного лучше чем 2.5 гбит свич всего на 50 евро дешевле.
И это все китай, если пойти на местные барахолки то цена иногда на порядок ниже.
В общем итоге если не надо тянуть кабели через всю квартиру, а достаточно соединить 2пк по 10гбит выйдет примерно раза в 2 дешевле по оптике чем по eth 10gbps, а 2,5гбит в 2 раза дешевле чем оптика.
У себя остановился пока на 2,5гбит, проблем вообще никаких нет, а скорость упирается в дешевые ссд в сервере с slc кешем на запись. mysku.club/blog/aliexpress/95555.html
Соедините два лаптопа по 10 гбит оптике. Результат, если он будет, пожалуйста оформите в виде отдельного обзора.
зы. я ж не против оптики, проблема в том что доступных адаптеров для нее нет и есть у меня подозрение что с внедрением WiFi 7 и не будет.
Сколько стоит ноут с нативным 10гбит портом?
А если надо 4 ноутбука соединить? А если еще с сервером?
В чем смысл изначально брать железо которое не особо подходит для задачи ( ну кроме поиска Edge кейсов что бы посраться в комментариях)?
Кстати даже так есть Usb-c на SFP+ адаптеры =)
Спор бесполезен, 10Гбит эзернет всем хорош кроме цены которая у sfp+ комплекта выходит дешевле если брать бу энтерпрайз.
Напомню условие задачи поставленное вами же
Вот я хочу соединить два ПК в форм-факторе ноутбука. И че? Дешевле выходит?
Дешевле всего будет в m.2 слот воткнуть рейзер а в него PCIE карту с SFP+ портом, все остальное уже заметно дороже.
Это уже пошли отмазки, в оригинале было 2пк.
>Но даже c eth 10gbps дешевле будет купить SFP+ на eth и всю остальную сеть на оптике держать, чем ради ноута переплачивать X2-3 за Rj45 eth pcie карты
Мне нравится как вы называете UTP кабель eth. Одного этого достаточно чтобы понять ваше знание предмета.
Чего уж не f/utp категории 6 и выше раз про 10гбит говорим?
Зы, сервер кстати вполне себе обычный пк, и ничем зачастую от него не отличается, опять докапываемся лишь бы было за что.
aliexpress.ru/item/1005005136837329.html
А вообще это хорошо, что вы протестировали воздействие увеличения Jumbo Frames при передаче дефолтного пакета iperf, но к реальной жизни это не имеет вообще никакого отношения
А у автора такие низкие скорости, вероятно, потому, что требуется настройка стека ОС.
Ну выяснили вы что размер фрейма 9000 лучше работает с пакетом 8kB чем размер фрейма 1500. Я как бы и без теста это знал. Дальше что?
mysku.club/blog/aliexpress/95555.html
Кстати юсб3 не должен был стать проблемой ибо он раза в 2 быстрее по спекам.
Я бы рекомендовал не трогать MTU совсем.
А вот если у вас есть выделенное дисковое хранилище (не NAS с самбой и торрентами, а именно iSCSI, NFS, или другой кровавый энтерпрайз) подключенное отдельным кабелем к вашему компьютеру, то вот там можно делать c MTU все что хочется.
Нет или незначительно (если говорить про коммутатор).
Сильно ниже: двухпортовые адаптеры на avito от 1200 руб, SFP+ (если речь про оптику) — от 350 руб (там же), коммутатор тоже дешевле. Причина: устройства 802.3bz появились относительно недавно, цены на них высоки; 10G же «в деле» очень давно, на вторичном рынке много устройств после апгрейда ДЦ (серверные сетевые карты), операторского оборудования (SFP, большие коммутаторы), сегмента SOHO (коммутаторы с небольшим числом портов).
В обычном «кейсе» им хватает их радиаторов и того обдува, что уже есть в системнике.
А большой коммутатор для дома не самое логичное применение в плане занимаемого места и скорее всего сильно шума даже на хх.
и по поводу sfp+ модулей, всегда считал что ту них есть некий ресурс, и хз какой он там остался, хотя это наверное больше актуально для LR оптики, т.е не актуально для домашней сети.
Asus XG-U2008 10gb (2 порта 10G, 8 портов 1G):
Tp-link TL-ST5008F (10xSFP+ 10G):
К тому же камеры могут хотеть PoE. Почему это всё не «воткнуть» в более дешёвый гигабитный коммутатор и не заниматься ерундой?
Дешёвыми коммутаторы 10G на 24 порта (т. е. с неблокируемой коммутацией 240 Gb) быть сейчас просто не могут. И это надо понимать.
Первый GBE коммутатор, купленный на работу, был тот ещё гроб, жрал и шумел очень сильно, а стоил вообще нереальных бабок. Сейчас его возможности запихнуты в маленькую пассивную коробочку, которую можно не напрягая домашнего бюджета купить и не мешая сну поставить в спальне.
Через одно-два поколения цена коммутаторов 2.5GBE приблизится к GBE, а потом то же произойдёт и с 10GBE. А кому хочется вот прям сейчас — купит дороже и будет мириться с шумом.
Спасибо за ответ!
300 МБ сильно меньше 1000МБ. 1000МБ минимум даже для дешёвых NVMe SSD с объёмом от 500ГБ на чтение.
Зачем такое нужно, могут спросить некоторые? Для видеомонтажа.
Представьте себе однополосную дорогу по которой едет машина на скорости 200 км.ч и перевозит она 4 человека за 1 час. Но вам нужно перевезти 8 человек за то же время. Можно увеличить скорость машины в 4 раза (туды-сюды два раза за то же самое время), но ездить на скорости 800кмч будет немного сложновато. Поэтому вы строите еще одну полосу по которой пускаете еще одну машину. Скорость машины не увеличилась, а количество груза перевезенного за то же время удвоилось.
Вот это и есть link aggregation.
«SMB Multichannel, a feature included with Windows Server 2012 R2 and Windows Server 2012 and part of the Server Message Block (SMB) 3.0 protocol, increases the network performance and availability of file servers.
…
Increased throughput. The file server can simultaneously transmit additional data by using multiple connections for high-speed network adapters or multiple network adapters.
Network fault tolerance. When clients simultaneously use multiple network connections, the clients can continue without interruption despite the loss of a network connection.
Automatic configuration. SMB Multichannel automatically discovers multiple available network paths and dynamically adds connections as necessary.» с сайта Микрософт.
В ютюбе если наберете «SMB3 Multichannel» там в первом же ролике Вам покажут, что файлы пересылаютс за в два раза меньшее время.
Вы спорите или соглашаетесь?
Ok, специально дла вас.
Link aggregation увеличивает пропускную способность соединения и скорость передачи файлов при использовании некоторых протоколов.
Link aggregation не увеличивает скорость соединения.
Так понятнее?
ТОгда уж логично взять что-то с linux / kvm, и там уже использовать zfs.
Кэшированием увлекаться имеет смысл при серьёзных серверных нагрузках, но не дома и не в малом офисе.
Дедупликакцией — тоже только при больших объёмах и нагрузках, иначе затраченные ресурсы многократно перевешивают выигрыш.
За много лет всё это изучено, описано и перепроверено.
2.5Gbit — отличный вариант сети для home/office NAS, недорого, доступно и быстро.
на 10G нет смысла тратиться, если нет сооотв. нагрузок (а там где они есть, давно всё на 10/40/++).
Подобные usb адаптеры имеют смысл для ноутов, да и то док-станция с кучей портов может оказаться интереснее.
здесь вопрос универсальности. если я хочу работать с удаленным диском не парясь что он сетевой, получая что то типо бюджетного nvme ссд по скорости, то без 10gbps тут никак, как и без кэшей и буферизации, если мы говорим о большом массиве, который должен быстро отдавать и быстро проглатывать большие объёмы данных. Сами по себе HDD в количестве нескольких штук вывезут только десятую часть от требуемой скорости, плюс по мелким блокам там будет печаль. Даже для дома такое решение по нынешним временам это медленно.
А про ZFS я скажу такое — даже компания которая владеет всей IP и десятками годами разработки этой файловой системы не использует ее под Linux даже для внутренних систем. Btrfs, кстати, тоже.
Кстати, ZFS использовалась бы на маках, если б не эта сделка. Apple свернула работы по интеграции ZFS из-за нее.
Убить MySQL, не случилосьУбить Java, не случилосьУбить Hardware Business, не случилосьУбить ZFS, ну типа того, но она просто оказалась не нужна, хотя поддержка в ядре Linux была реализована больше 10 лет назад. При этом открыла код, ну а то что кому-то не понравилась CDDL, чьи это проблемы?
Что там еще было у Sun что оказалось никому не нужным? OpenOffice? То же самое.
Идея про то что Oracle купил Sun чтобы Apple не получила
ZFS одна из самых смешных что я слышал, Ларри и Стив были лучшими друзьями и компании никогда не конкурировали ни на одном рынке.
ps. про то как разваливается ZFS на 2PB массиве на оракловом файлере под Solaris я могу рассказывать часами, именно поэтому и держусь от нее как можно дальше.
Плюс очень не любит синхронную запись, особенно если хорошо нагрузить в кучу потоков, очень часто возникают race conditions, особенно когда у вас заканчиваются ZIL и SLOG.
Может в консерватории что-то поправить надо? ©
ZFS кроме файловой системы еще и менеджер устройств, так что да, правильная работа с дисками это ее прямая обязанность.
А в пионерлагере что-то поправить точно надо.
Это Ваша выдумка, сами опровергаете свои же фантазии-сказки.
Была? Правда что-ли? Прям в ядре? Кто ее туда вставил то 10 лет назад, если не секрет?
ZFS должна была выйти как часть UEK и активно тестировлась внутри компании, вы ее увидеть не могли даже при всем вашем желании.
Общение с вами хотелось бы закончить гениальной фразой Раневской про пионэров.