RAID5 + FS + SSD(TRIM)

Попробуйте Btrfs, там встроенный raid и trim работает.

мне рекомендовали использовать файловую систему XFS. Но и он не дает создать раздел с блоком меньше 512.

А вам никто не даст блоки меньше 512.

и как быть?

Размер страницы ssd исчисляется десятками-сотнями килобайт, чанка рейда тоже.

В этом случае наоборот имеет смысл делать блоки больше, дабы не париться с переписыванием чанков на мелких операциях.

SSD
размер блока ниже 1024

УПРЛС?

Но и он не дает создать раздел с блоком меньше 512.

Мальчик, убери руки от клавиатуры, пока ничего не сломал. Для SSD размер блока меньше 4096 -проседание производительности и повышенный износ.

MDADM НЕ мешает делать Trim.

Сначала приведи модели SSD. А перед этим загугли, не забанены ли они в ядре. Тогда, может, поймешь.

В догонку. Перечитывай до просветления. Не включается TRIM на Samsung EVO (комментарий)

Хорошо. Не мешает.

Почему же тогда трим не отрабатывает на ext4 разделе в массиве? А вне его - спокойно себе отрабатывает? Это уже говорит о том, что в ядре он не забанен.

Модель 2.5" 480Gb CRUCIAL SSD SATA-III M510DC (MTFDDAK480MBP)

Since version 3.7 of the Linux kernel mainline, md supports TRIM operations for the underlying solid-state drives (SSDs), for linear, RAID 0, RAID 1, RAID 5 and RAID 10 layouts.

То-есть или у тебя ядро старше 3.7 или ты принимаешь за неработоспособность TRIM что-то другое.

А на 3.16 нет?

Я просто сейчас тестирую на livecd Debian.

Но изначально не работало и в самой системе под 4.9.

определяю по команде fstrim, которое собираюсь применять по расписанию.

На раздел в массиве ругается вот так.

# fstrim -v /
fstrim: /: the discard operation is not supported

Если я выну диск из массива, создам на нем раздел и прогоню fstrim, то она работает.

Ок. А если примонтировать ФС с опцией discard и посмотреть вывод dmesg | tail по поводу монтирования?

Пишет, пишет следующее:

EXT4-fs (md0): mounting with "discard" option, but the device does not support discard

Тебе ж ответили в другой теме, что тебе надо уменьшить размер чанка в рейде и увеличить размер блока в ФС. Причём чанк должен по идее быть меньше блока ФС в количество раз равное количеству дисков на которые ведётся запись в рейде. То-есть при рейде 10 из 4 дисков и чанке в 64к, блок в ФС должен быть 128к, а при рейде 0 из 4 дисков и чанке в 64к, блок в ФС должен быть 256к и больше.

XFS автоматом устанавливает параметры в зависимости от параметров рейда на котором её разворачивают. Но больше метра она всё равно не сможет сделать блок.

Думаю что это нонсенс по определению. И то что здесь советовали про изменение размеров блока - это бред, чтобы казаться умным.

Нанем снизу: те кто точно знают как работает трим могут пропустить Есть современный емкий ssd, у которого достаточно большая область очистки ~2MB. Когда мы пишем любые данные (сектор, 512 байт) в какую-то часть этого блока - ЕСЛИ это часть блока ранее не использовалась (в ней только нули) то ssd туда данные просто запишет. Если нет - читаются данные из этого 2M блока, в них меняются 512 байт (сектор) и 2M пишутся в другой блок, заранее очищенный. т.е. хотим переписать 512B, но внутри переписывается 2М. пишем 1 сектор, переписываются 4 096 секторов.

команда trim сообщает ssd, что данные «тут, тут и тут» уже не нужны. ssd читает блок, заменяет данные «тут, тут и тут» на нули и при следующей записи в эти сектора можно будет просто писать, не занимаясь очисткой. Если из 4096 секторов у нас занята половина, а остальную постриг трим - можем продлить жизнь ssd до 2000 раз. Ну, это конечно сказочный вариант.

Теперь raid5 и chunk: у него есть chunk (область, в которой данные подряд пишутся на один диск, до перескока на следующий). Для шпиндельных дисков длинный chunk означал, что при чтении записи есть шанс прочитать подряд 100500 секторов с одного цилиндра не двигая головкой, или используя быстрый скачек track-to-track. Read-ahead короче. А также возможность читать одновременно 2 достаточно длинных файла с 2-х разных дисков, не мешая друг-другу.

Для ssd короткий chunk (меньше области очистки) означает что вместо того чтобы записать линейно 2MB на один диск, и истратив одну (без выравнивания - 2), а с парити 2 (4) процедуры очистки блока вы с 64КБ чанком размажете эти данные по всем дискам массива (7+1) и израсходуете 8 (16) очисток. Т.е. уменьшение ресурса ssd в 4 раза на линейных операциях, и никакой выгоды на случайных. Профит налицо!

Теперь raid5 + trim: если имеем 8 дисков, то 7 чанков занимают данные, а восьмой - парити. Ну, там коды Рида-Соломона, конечно, и все дела. Это мутно. Но главное что нужно понять - при любом изменении любого бита данных блок парити меняется полностью. И должен быть перезаписан тоже полностью.

Какой-то смысл trim на чанках с данными конечно может иметь, но в любом случае при записи каждого блока наново переписывается chunk с parity.

А после выполнения trim на блоке данных одного из дисков парити должно быть такжн полностью переписано, причем немедленно, иначе в случае сбоя этот блок данных (7 чанков + парити) будет не сходиться. т.е. на 7 дисков выполнили trim = 7 раз переписали парити = никакой реальной пользы от трима, диски все равно стаптываются.

=== Короче - оставьте на диске, который хотите собрать в raid5 10% не размечеными в таблице разделов, и собирайте raid5 без trim с чанком равным размеру блока очистки этого ssd (который почему-то в официальных источниках указывают редко, но опытным путем его определяют достаточно точно)

Весьма благодарю.

Опытным путем так и сделал, хотя честно говоря, на угад - редукционистским путем.

А можете подсказать на счет ситуации с RAID0?

Подскажу, если расскажете в чем ситуация.

Какие проблемы с реализацией RAID0 или черезстрочным LVM массивом и TRIM могут возникнуть?

Смысл заключается в том, что реализация с LVM у меня периодически крашилась фс одного из логических томов, зачастую при обработке задач на Jenkins

Может ли подобное случится с RAID0?

fs до лампочки как называется пакет, которым вы ее грузите. а mdadm и lvm почти до лампочки какая fs на них стоит.

Рояль играет линейность или рандомность операций записи, и размеры блоков. Чтение ssd переваривают в любых позах не икая.

Зачем вам именно raid0? для объема, или для скорости? Что за ssd использовались?

Для объема с учетом равного износа.

Ни LVM ни Raid0 не должны добавлять битовые ошибки или приводить к сбоям файловой системы. 99% что это проблемы оборудования.

Износ в raid0 будет равным для всех ssd в нем, но в сумме большим, чем просто последовательная склейка. Выше уже объяснял, что для не большего износа нужно точно знать размер блока очистки и чтобы размер чанка в рейде был таким же И чтобы начало раздела было правильно выровнено.

Самое рациональное решение имхо - на основе каждого ssd-шника сделать degraded raid1, а получившиеся устройства склеить последовательно. Таким образом можно будет заменить без простоя любой из ssd, когда у него wearout будет опасным.