Помогите выбрать ФС на несколько дисков в условный raid0

sd? это названия физических томов

анекдоты тебе тоже два раза рассказывать надо?

Я писал ручное распределение лв по пв когда в клауде работал. Там нет подвоха :-) а касательно рейда из двух маленьких это не очень идея ибо затруднит миграцию с заменой диска

Всё просто. Рейдовый лв состоит из четырех частей, meta1, meta2, linear1 и linear2. Linear - это скрытые тома с данными, мета понятно что. Linear1 у тебя на sda1 + sdb1, linear2 на sdc1. Вот и всей магии.

Как вариант можно создать по другому,

Lvcreate -n mylv -L 59G myvg /dev/sda1 /dev/sdb1

Потом посмотри pvscan чтобы увидеть как занялось место. И потом

Lvchange –type raid1 -m 1 /dev/vgname/mylv

ceph на одной ноде и с 512 памяти будет жутко тормозить

Упомянутый mergerfs выглядит прикольно, но я бы сделал проще: lvm на все диски, ext4 и если есть какие-то важные данные, то бекапить по крону куда-то. Хотя я не представляю, какие важные уникальные данные можно доверить такому железу. Как дополнительный узел syncthing или торрентокачалка - может быть.

Ещё добавлю к mergerfs. Торрентокачалкой качать/раздавать я делал в исходные директории. Которые до слияния

Уже подсказали...

Но я его отмёл по другому: там псевдослучайный алгоритм разброса данных по хранилищам, он будет довольно хреново самобалансироваться когда место на одном из дисков закончится. Вплоть до переключения в ro на ~20-40% заполнения. Всё таки Цеф не рассчитан на говножелезо, только на слабые или мощные серверы с энтерпрайзными дисками.

Так сама суть этой темы - найти альтернативу, в которой можно получить назад часть данных при крахе диска или мягко вывести том из массива если диск начнёт умирать. И lvm, и ехт4 так не позволит.

но ходят слухи что есть ФС (btrfs?),

Вот появилась новость: https://www.opennet.ru/opennews/art.shtml?num=63964

Из новости самое интересное то что btrfs сильно сливает ext4, xfs и F2FS.

От новостей про б-кэш всё ещё попахивает политикой и старым Товальдсосрачем... А насчёт тестов - хз что там с оптимизацией сложного массива и условиями тестов, он вроде бы не обязан всегда выдавать стабильные и высокие скорости. Похоже там обычный ссд и стандартные условия теста.

А насчёт тестов

В тестах самое нормальное то что там есть другие результаты.

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

Ну думаю мысль вы поняли.

Мысль понял, не согласен что она применима здесь. Бронетракторная ФС требует тюнинга, а на стандартных настройках CoW + журнал + контрольные суммы + готовность сделать снапшот это не про производительность. Если бы они отключили cow - рандомизированная перезапись явно работала бы по другому. Аналогично рейд 5/6 не могут сравниться по скорости с одиночным диском или простым зеркалом.

Мысль понял, не согласен что она применима здесь.

Вот еще подвалила: Linux 6.17 File-System Benchmarks, Including OpenZFS & Bcachefs

btrfs или в отстое или максимум в середине.

А что там такого криминального? Классические ФС отдельно, фичастые отдельно. За фичи приходится платить. btrfs почти по всем тестам лучший компромис чем zfs.

Если тебе один фиг на пощупать я бы пощупал zfs.

Вроде сносно сейчас на лине работает.

Raspberry Pi 1B

zfs

Такое себе щупанье.

Тем более openZFS модулем под распбиан собирать...

Да, но есть одно «но»: насколько этот тест непредвзят и кому из корпораций он нужен, а что он нужен, сомнению не подлежит :)

Да ладно.

Вот я на Fedora ставлю nvidia c rpm-fusion c akmod,
а в RL9 ставлю nvidia c el-repo прямо в kmod.

Сборка модуля не самое печальное. 1 ядро, 512 метров памяти подарят незабываемый юзер экспириенс, особенно если захочется пользовать фичи фс типа компрессии, дедубликации, автоснапшотов.