Melkij

SSD берут ради скорости, тем более внятные на запись серверные SSD.
RAID5 или 6 ставят ради стоимости хранения гигабайта ценой заметного ущерба производительности записи.
То есть не очень понятно, с какой целью вы рассматриваете 5 или 6 рейд на хороших SSD. Если важен объём - то берите более дешёвые S45xx

и вообще у кого есть опыт использования ssd в рейдах на длительный срок(3-5 лет) как себя ведут ssd

Intel - отлично себя ведут. Даже при проблемах с питанием, у них штатный конденсатор, держащий достаточно энергии для корректной записи всего что диск пообещал системе. В спеках описано как Enhanced Power Loss Data Protection
У нас в эксплуатации много intel'ов разных лет (давно за сотню штук) Меняли в основном потому что в объём упирались. С отказом диска встречались только один раз. И это всё в условиях под постоянной нагрузкой СУБД postgresql.
В общем, мы безоговорочно рекомендуем брать в сервера интеловские SSD (если получается) за надёжность и предсказуемый latency под нагрузкой. Другие диски - очень сильно по разному себя ведут.

2) исходя из вопроса, есть смысл делать рейды 5 или 6 если все равно на все ссд пишется сразу данные ? получается к концу обьема записи ssd придется менять все диски сразу если какой раньше не вышел из строя

Я не вижу смысла в 5/6 рейдах на хороших SSD не касаясь Lifetime Writes

1) в этом контроллере есть hp smartpath, при его включении линейные скорость значительно ниже, примерно в 2 раза нежели при включении встроенного кеша, имеет смысл его вкл(smartpath или выключать) ?

Лучше softraid. Серьёзно. Без шуток. Глупый HBA и softraid.
hardraid под хорошие SSD надо или очень пристально настраивать хорошо зная свой контроллер или вы будете упираться в производительность контроллера, а не в диски.
PS: зачем вам линейные скорости под базы и виртуалки? Тестируйте random io.

И тот и другой гарантируют выживаемость при отказе только одного любого диска. И оба могут выдержать отсутствие до половины, но строго определённых дисков. Потому гарантии надёжности одинаковы - один диск массива.

Следует упомянуть, что конкретные реализации могут понимать под raid10 что-нибудь другое относительно классических примеров зеркало поверх страйпа или страйп поверх зеркала. Например, mdadm можно настроить писать raid10 разными способами, в том числе на произвольном числе дисков (например, raid10 на 5 дисках с равной утилизацией каждого) и с конфигурируемым объёмом избыточности (например, чтобы переживать смерть любых 2 дисков, но тогда общая ёмкость массива будет не raw/2, а raw/3)

Коробка под диски для прямого подключение (а не сетевого т.е. NAS) правильно гуглится как DAS, Direct-attached storage
А вот с NAS оборудованными USB портами как раз поаккуратнее, зачастую это USB-хост и к ПК не подключается.

Например

Хранилище чего именно? Я без проблем могу себе представить нагруженную СУБД на 10Тб (и немного за 20Тб сырой ёмкости накопителей), которая не взлетит на HDD вообще как раз из-за требований к времени доступа и все эти 20Тб набраны серверными SSD.
И могу себе ещё более легко представить хранилище на 10тб под бекапы, где производительность должна быть просто достаточной за разумное время положить новый бекап или прочитать нужный при аварии, для чего достаточно raid5 или 6, а может дешевле окажется и вовсе пара 10тб дисков, надо с прайсом уже смотреть.

Сначала задачи, ограничения применения, пределы дальнейшего расширения, бюджет на всю хранилку - и только потом сколько надо будет заказать дисков.
Для хранения 10тб информации необходим хотя бы один накопитель (задача может сказать, что диск резервировать не нужно, такое тоже бывает). Всё остальное выбирается под конкретику.

Вы так говорите будто инсталлятор сделает raid чем-то иным нежели linux raid (aka mdadm).

Поддержка trim под linux raid - вопрос версии ядра linux (ну может ещё каких крайне нестандартных ядер).

Отмонтируйте файловую систему и сделайте глупый dd if=/dev/md0 of=/dev/раздел большого диска. И будет копия целиком файловой системы со всеми софт/хардлинками, разреженными файлами и всем чем надо. Затем resizee2fs для расширения ФС до ёмкости раздела.

А если вы хотите плавно заменить массива на более ёмкие - то вам вообще файлы копировать не надо. Добавить диски побольше, подождать синхронизацию, удалить старые диски и сделать resize2fs ru.stackoverflow.com/a/637847/203622

производительность будет упираться в скорость 1 диска, т.к. после каждой записи нужно будет обновлять диск паритета

Это raid4 с отдельным диском под хранение избыточности.
В 5 и 6 избыточные блоки размазываются равномерно по всем дискам массива, а не выделяется отдельный диск для хранения избыточного блока.

/sys/block/md?/md/stripe_cache_size поправили? Bitmap внутренний/внешний/отключен? С внутренним производительность записи тоже неплохо просаживается.

Само устройство - никак. С диском должно общаться ядро. У контейнера своего ядра нет.
Монтируете диски к хост-системе, биндите в контейнер: https://wiki.debian.org/LXC#Bind_mounts_inside_the...

Софтовый рейд вас не ограничивает глупостями вроде 1 диск может быть только в одном массиве. Можно разделы одного диска объединять в разные массивы.
Пилить диски можно как угодно. Например, распилить 3тб диски каждый на два раздела: по 1 и по 2тб каждый. Собрать в итоге два raid5: 3 тома по 1тб и три по 2тб. Итого 6тб форматированной ёмкости, допустимо выпадение любого диска массива. При необходимости в едином куске места - поверх этого развернуть LVM.
Наращивать можно дисками любого размера, условие одно: добавляемый том не меньше используемого размера тома в действующем массиве.

Про raid5 в домашних NAS - у меня два диска разом за 8 лет не умирало. Дефолтно в debian включен кроновый скрипт верификации всех софтовых рейдов раз в месяц. Пару дисков проблемных он и обнаружил заблаговременно.
Но вот два диска разом выпасть из массива - это было. Кабель питания отошёл. Собрать обратно массив удалось, а вот ФС побилась. Но у меня был бекап, потеряны только неважные данные.

Если нет никакой возможности использовать географически-удалённое место для бекапа, то для бекапа можно выделить области на этих дисках. Только не в составе чего-то сложного (lvm, raid) и не на том же диске, где лежит основная копия! Можно использовать raid1 при необходимости продолжать работу при отказе диска - зеркало хоть восстанавливать просто и достаточно одного любого диска.
Например, порезать 3тб диски на два раздела: 2тб и 1 тб. Затем собрать raid5 на трёх 2тб томах - под всякое не очень нужное. Три раздела по 1 тб - под важные данные. Можно собрать raid1 из двух дисков. Но не как зеркало из всех 3 дисков! Это только от физической поломки поможет, а от проблемы с ФС - уже нет. Один раздел не должен быть примонтирован постоянно, монтируется только на время бекапа основной части. rsync в кроне как самый простой вариант. Лучше бы, как уже советовали, 3 независимых тома: актуальная копия, горячий регулярный бекап, последний диск под холодный бекап, его физически отключать (можно сколхозить автоматический девайс для размыкания цепей на твердотельных реле).

В mdadm raid10 собирается не как страйп над зеркалом и не как зеркало над страйпом, а как единый массив, данные при этом размазываются и дублируются по принципу, указанному при создании массива опцией --layout, см. в man mdadm.

Грузился ли с деградировавшего массива во время моих экспериментов - не помню, но то что данные не терялись и массив продолжал работать при потере нескольких определённых дисков - это да.
Но near2 гарантирует целостность только при выходе одного диска. Второй - уже как повезёт.

Во-первых, снимите с каждого отдельного диска посекторную копию.
Только после этого можно что-то делать.

Попробуйте запуститься с linux с linux raid. Судя по объёму дисков, массив старый. Есть вероятность, что массив подцепится автоматически.