Nikolay_Po (01.12.2021 11:17, просмотров: 416) ответил Nikolay_Po на SSD NVME M.2, пара штук на материнской плате. Каждый более 1ГБ/с
запись. Можно в RAID0. Сейчас у меня они в RAID1 и работают как
блочный кэш чтения/записи массива RAID5 из HDD (bcache). Кэш записи
- 23ГБ, 207ГБ кэш чтения. Запускаю в своей системе виртуальную
машину с Windows 10, в ней CrystalDiskMark. И получаю скорости
чтения/записи на файлах 4ГБ в 1400..1700МБ/с. Ну оно так и
работает.Так вот, связка mdadm и bcache-tools показала себя превосходно в плане устойчивости в ходе работ. Отмечу, с чем столкнулся при увеличении размера кэшируемого RAID:
1. Размер раздела блочного накопителя, который использует MDADM для томов RAID, может быть легко изменён в большую сторону любой утилитой, например, консольной parted, командой resizepart.
2. Размер тома RAID меняется до максимума легко, командой mdadm --grow /dev/md127 -z max. В таком случае, используется всё пространство выделенного тома накопителя. Так же успешно менял размер тома в меньшую сторону. Важно только проверить, что размещённая в томе файловая система не превосходит новый, урезанный размер.
3. При сборке массива, у которого том менял размер, возникнет проблема, когда в суперблоке RAID указан старый размер, хотя размер тома уже изменён. В таком случае требуется обновление информации о размере в суперблоках томов: mdadm --assemble /dev/md/devicename --update=devicesize
4. Так уж случилось, но при создании нескольких массивов RAID в одной системе, пара разных массивов имела одинаковое имя тома. Имя тома RAID прописывается в суперблоках томов массива. И оно работало с одинаковыми именами, но собрать такой массив после остановки обратно, я уже не смог. Способ поменять имя тома нашёлся, вот он: mdadm --assemble /dev/md/devicename --name=newname --update=name /dev/sd[gf].
5. В общем, несмотря на попытки убить уже и так деградировавший массив изменением размера и переименованием, ничего не потерялось. В худшем случае массив не собирался с жалобой на неверный параметр, но данные не повреждались. Просто проследите при сборке, что данные каждого тома массива, отображаемые по команде mdadm --misc --examine /dev/sdxy, соответствуют друг другу, и "Avail Dev Size" соответствовал "Array Size".
6. После изменения размера тома RAID, на котором размещён том bcache, с bcache ничего делать не надо! Том bcache не содержит в заголовке информации о размере, поэтому после изменения размера своего носителя, размер тома bcache изменяется автоматически. Единственное что, перед тем как менять размер тома bcache, я выключал кэширование в состояние "none" и ждал, пока пройдёт запись на HDD данных из кэша записи. В противном случае, гипотетически можно потерять данные - у меня нет информации, что структура данных в кэше сохранит соответствие структуре данных кэшируемого накопителя при изменении размера последнего.
7. Увеличение размера файловой системы ext4, размещённой в кэшированном томе bcache было тривиальным: resize2fs /dev/bcache0
8. Что бы я ни делал, за исключением отказа в сборке RAID по неверным параметрам суперблоков, после перезагрузки или по команде partprobe, том bcache всегда тут как тут! Даже доставляло неудобство его каждый раз останавливать, чтобы провести изменения размеров или разобрать RAID. В принципе, система блокирует попытки изменений устройств "на живую", до тех пор, пока не остановишь всё по цепочке с конца. Это приятно. Ничего сломать не удалось.
9. Когда нужно разобраться с RAID, который не собирается, помогает команда mdadm --misc --examine /dev/sdxy. В выводе видны UUID массива, имя, размер и состояние тома. Там, где состояние "clean" и не указан Recovery Offset - это рабочий, целый том массива. Там, где указан Recovery Offset - это том в процессе синхронизации. На его целостность данных рассчитывать нечего. Ну и как писал выше, нужно убедиться, что параметры всех томов массива до сборки соответствуют друг другу.
И да, в этой системе, кеширующие накопители SSD, один SATA, другой USB-flash, так же объединены в программный RAID. Это сделано для того, чтобы пользоваться кэшированием записи во FLASH, обеспечивая при этом утойчивость к отказу одного из FLASH-накопителей. Структура похожа на ту, что в моём сообщении уровнем выше, только HDD объединены в RAID1 вместо RAID5.
Вывод: mdadm+bcache - моя любимая связка, позволяющая получить быструю, отказоустойчивую, но недорогую за счёт экономии на объёмах SSD, систему для Linux и виртуальных машин.
Рекомендую. Уже не первый раз, и ничего не сломалось, не повредилось, не потерялось, не сбойнуло.