Исходное сообщение
"Релиз ядра Linux 6.7" Отправлено Аноним, 08-Янв-24 15:12
Сетап - для хомяка ноутбучный SMR на терабайт, в качестве кэша - Kingston UV400 га 240 гигабайт. Сжатие - lz4 в бэкграунде. Ну т.е. ссд в качестве writeback кэша, во время ребаланса происходит сжатие данных и запись на бэкграунд HDD. Минусы - то, что тулзы местами недоделанные. Например, если смотреть rebalance status - то нихрена непонятно, сколько ему еще ребалансить. Нельзя вызвать ребаланс самому или изменить триггеры, вызывающие ребаланс. Это не мешает, но я хочу, например, делать ребаланс чаще. Так же, например, изменение таргета для метаданных не заставляет при очередном ребалансе метаданные переносить с носителя на выбранный полностью, приходится лапками мув данных запускать. Мелочи, в общем. RAID5/6 использовать не рекомендуется пока, насколько я понял, а так же _нельзя_ использовать erasure coding - ибо нестабильно. А вымораживает меня то, что оно не дает винту стопнуть шпиндель - раз в секунду что-то читается, или журналы сбрасываются. Я пока не понял, можно ли журнал убрать с HDD. Жить не мешает, но т.к. все нужные данные обычно в кэше (там обычный LRU) - мне хочется, чтобы хард стопался через минут так 5 неактивности, а вот хрен то там. Подозреваю, в следующих релизах поправят. Если погуглить - есть жалобы на nocow - мол, корраптит файлы - вот это жирный косяк, но вроде по последним коммитам что-то в этом направлении было сделано в rc7). Есть жалобы, что девайс не всегда получается вывести из массива, но тут я не тестил - и, в общем, понятно, что это будет исправляться - вроде как в linux-next там на эту тему тоже что-то заброшено. Есть косяк, что если смотреть rebalance_status из sysfs - оно IO считает в каких-то странных единицах, ошибка в выводе времени отображения ожидания ребаланса (200 секунд отображаются как 200 минут, а 3600 секунд - как 3600 часов) - но, я так понимаю, Кенту на это начхать пока что, да оно и не важно. Пережило с десяток отключений питания, нормально работает в гибернации (я использую для хомяка, корень у меня на другом SSD). Восстановление после сбоя бывает длительным, но пока ничего не потерялось. Монтируется оно у меня в rc.local, бо mount почему-то плющило и systemd висла, поэтому на корень я бы это тоже ставить не стал. Почему оно лучше чем btrfs - так это я свободное место могу нормально видеть, там зарезервировано, кстати, в дефолте 8%. Собственно, сжатие тоже как-то странную статистику показывает, но то, что у меня на 200 гиг раздел свободнее чем планировалось - таки да. uncompressed:         nr extents:             3684626         size:                   507 GiB compressed:         nr extents:             3724187         compressed size:        216 GiB         uncompressed size:      448 GiB incompressible:         nr extents:             10889179         size:                   622 GiB В общем, при наличии бэкапа - мне нравится. Без бэкапа я бы тыкать не стал как минимум до следующего LTS.