> На самом деле он уже несколько лет как многодевайсный, при создании ФС
> (и позже тоже) есть режим который объединяет несколько разных устройств в одну ФС.

О, и правда завезли. Но ты уж извини, там про лишь рассмотрение как 1 большого девайса, а это по надежности... ну знаешь, у меня оно пару раз при тестах и с 1 девайсом наповал подыхало, да так что ни ядром смонтировать, ни fsck не чинит - и в общем то финиш. На этот случай плана нет совсем. А если туда эн девайсов еще - это ж как я понимаю не RAID с избыточностью, а нечто типа абстракции типа JBOD, и оно скопытится еще быстрее стал быть. Я своим данным не настолько враг.

> Там и много поточность задумана и вцелом оно так быстрее.

Многопоточность можно сделать и без таких извращений с девайсами, XFSники проверяли. А для вон того звездного крейсера btrfs - так то тоже Mk II для гипердрайва как раз именно эту тему обыгрывает. Известно под кодовым именем "Extent Tree v2", пока WIP и не финализовано.

А тут еще кентушка вот - посмотрел на это все и в целом "содрал с btrfs" только основательно облегчив, ускорив и озаботившись еще и иерархией девайсов и учетом свойств. Что как бы круто и правильно. CoW write-anywhere аллокатор и фоновая логика может учитывать свойства носителей и статистику обращений при решениях. Почему нет? Хорошо когда о такой крути подумано на фазе дизайна.

> Но есть косяк - никаких особых метаданных идентифицирующих отдельные "тома"в связке нет,
> поэтому если при создании использовать имена устройств вида /dev/sda оно так
> к этим именам жестко и привяжется. Не дай Бг у вас
> изменится имя хоть одного девайса в связке и ФС не смонтируется.

Я уже догадался что f2fs не парится сохранностью данных когда при powerloss-тестах он у меня вскоре скончался и fsck не смог починить до моунтабельного состояния. А вон то дополняет общую картину. Не думаю что среднего пошиба кодеры серьезно умеют в "архитектуру", это даже не мэйсон хотя-бы. И даже не кент слизывающий идеи с лучших из. Это замордованый корейский кодер на котором висело 3-4 здоровых проекта. Тут даже если умеешь в архитектуру, на это тупо ресурсов не хватит. Человек может воротить в единицу времени ограниченный объем работ, и манагерье из самса явно забыло про такую фигню. Ну оно и работает под стать, f2fs стремноватая штука, в ksmbd cve'шки и проч. Скажите спасибо что с такой нехваткой ресурсов вообще трепыхается как-то.

Для референса, btrfs вообще ни разу на таких тестах не сдох. Ext4 тоже в принципе живет, но в конце концов он мне начал икаться тем что все может сдохнуть на рандомных единичных бэдах. С парой тазиков может и терпимо, а если выводки одноплатников гонять, годами - такое себе, пришлось btrfs с схемой DUP любить, более живуче получилось + раннее предупреждение.

> Выход из этого есть - создавать на каждом устройсве таблицы разделов с
> 1 разделом  и при форматировании собирать их в связку адресами
> по UUID разделов.

Я конечно понимаю что некоторые любят сами фигачить кувалдой по колесу телеги. Но вот сходишь так, посмотришь как промробот все 4 колеса за секунды привинчивает и понимаещь что это можно делать и поприличнее уже. Да и ради чего это все? У этой шляпы даже чексум на данные как я понимаю нет, а с ее надежностью пачка девайсов - улучшает шансы на залет.

> Проблема в том что документация у F2fs очень так себе. Все буквально
> надо методом проб и ошибок выяснять. Самсунг такой самсунг.

У нее по моему ВСЕ ВООБЩЕ - "так себе". Потому что 1 перегруженного jeon'а на все и сразу ну вот никак не хватает. Чувак просто в какой-то момент зашился окончательно. Нельзя столько работ на 1 чела подвешивать, результатом их хреновое выполнение становится.