Calculate Forum

Оч. умелые ручки, или как пристроить к делу бесполезную вещь.

#1

Получил я тут задаром старый медленный SSD на 8ГБ. Ну то есть совсем маленький - ни туда, ни сюда. Прежний хозяин его хапнул на распродаже совсем задёшево, но куда примостить - так и не придумал.

Класть хорошую вещь на полку - не наш метод. В результате девайсу нашлось достойное применение в моём десктопе, где он, невзирая на свои скромные характеристики, продемонстрировал достойные результаты. Старичок был утилизирован следующим образом:

1) Раздел 300МБ под /boot. Read only, маленький - идеальный кандидат.
2) Раздел 1ГБ ушёл под внешний журнал ext3 для хомяка. Это дало прибавку по тестам диска от 10% до 500% в зависимости от вида нагрузки.
3) Остаток пространства был размечен в btrfs с двумя (пока) subvolumes - куда были перенесены ~/.cache\ и~/.config соответственно. Возможно, придумаю, что ещё можно туда закинуть - места ещё навалом. Был бы сабж хотя бы 16ГБ, можно было бы туда задвинуть рабочие директории portage, но на оставшиеся 5ГБ они точно не влезут… Но и так ускорение получилось весьма заметное даже безо всяких тестов.

#2

Еще, как вариант, можно ускорить всю дисковую подсистему, прикрутив ssd кэшем: https://www.kernel.org/doc/Documentation/bcache.txt или https://www.kernel.org/doc/Documentation/device-mapper/cache.txt

З.Ы. Сам не пробовал, как-то случая не представилось, но отзывы в интернетах вполне позитивные.

#3

Ага, я как раз с bcache и начал теоретические изыскания. Мой вариант проще. btrfs уже полюбому в ядре, а bcache надо прикручивать. К тому же bcache под разной нагрузкой по-разному себя проявляет, т.е. надо тестировать под конкретную нагрузку, а на для десктопа какие тесты - только военно-морской глаз))) Меня конкретно больше всего заботила производительность darktable, дабы 24-Мпикс фотки шевелились без удручающих задержек. И кэш, и library.db в результате поселились на SSD - полагаю, это всё же интереснее, чем кэшированная запись на HDD, хотя и менее надёжно.

Вот хорошая ссылка про SSD-шные улучшалки:

http://raid6.com.au/posts/SSD_caching/

#4

Bcache в ядре, кажется с 3.10.

 # zcat /proc/config.gz | grep -i bcache
CONFIG_BCACHE=m
 # CONFIG_BCACHE_DEBUG is not set
 # CONFIG_BCACHE_EDEBUG is not set
 # CONFIG_BCACHE_CLOSURES_DEBUG is not set
CONFIG_FS_MBCACHE=m

 # uname -r
3.10.25-calculate

Вот тут (http://maestromony.blogspot.ru/2013/09/gentoo-bcache.html) нашлась инфа о сборке initramfs, для загрузки с кэшируемого устройства.

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

Btrfs же, не знаю как сейчас, но пару лет назад, после некоторого времени активного использования, съедала очень много места под метаданные, вплоть до 30%.

#5

Цена COW - бОльшая фрагментация, тут уж ничего не поделаешь. Насчёт 30% - будем посмотреть. Я только недавно переехал с ноутбука на десктоп. Там у меня была JFS везде, для экономии батарейки. Хорошо себя показала, кстати - только зависов ядра недолюбливает - останавливайте её, видите ли, как положено, и всё тут. Хотя данные (один файл, зато какой - конфиг компиза!) потерялись всего однажды (а ноут уже второй). А пока я fglrx до ума довёл - зависы случались. На моём железе этот гад вешал ядро при попытке остановить систему или перезапустить иксы. А работал при этом практически без нареканий - ну то есть запустил и работай, нечего перезагружаться понапрасну))) TOI при этом тоже работал как положено (ну, почти).

И по месту: перенос 124ГБ данных с JFS на ext4 вылился аж в 138ГБ!
Так что Btrfs у меня свежак - захотелось попробовать для /. Уж очень откатываться удобно в случае неудачного эксперимента. Да и многоголовых разделов мне очень не хватало последние 30 лет)) А тут - свершилось! Реализовали! Грех не пощупать.

У меня линукс в сугубо домашнем применении, так что никаких логических томов не держу за ненадобностью - KISS в действии)). Хотя да - ваш вариант тоже вполне красиво смотрится. Буду иметь в виду.

#6

Скорее всего терялись и другие, менее критичные файлы, с которыми активно велась работа, например, из кэша браузера. Просто это не отражалось явным образом на работе.
Для надежного хранения данных (если, конечно, интересно) выбрал для себя ext4 с опциями noatime,nodelalloc,auto_da_alloc,barrier,data=ordered и fsck p при каждом старте прекрасно переживает некорректные выключения и зависания. Конечно полностью гарантировать сохранность данных может только режим data=journal, но скорость будет в 10 раз ниже, и как показывает практика, data=ordered и наличие регулярных инкрементальных бэкапов - вполне приемлемый компромис.
KISS это правильно, я и сам стараюсь придерживаться сего замечательного принципа, и менеджер логических томов, на мой взгляд, как нельзя лучше для этого подходит, в контексте управления дисками и файловыми системами =). Никакого особого усложнения в систему он не привносит, но гибкости добавляет и администрирование упрощает очень значительно. Во-первых, при изменении размера раздела, избавляет от необходимости двигать соседние. Во-вторых, можно не ломать голову как разбить диск и сколько выделить места каждому разделу - выделяю по минимому, и по мере необходимости довыделяю нужным разделам, прямо по живому, без отмонтирования. В-третьих, использовать логические тома, как диски для виртуалок - вообще милое дело =). В-четвертых, снапшоты, опять же, кстати. В-пятых, простота смены физического носителя - новый диск добавляется в ту же группу томов, все экстенты одной командой переносятся на него и старый диск извлекается. Операция проходит абсолютно прозрачно для логических томов, если не считать снижения скорости, вызванной загрузкой дисковой подсистемы копированием экстентов. Был случай, когда эти свойства позволили мне на системе загруженной с RAID5-массива созданного с помощью mdadm, разобрать этот самый массив и собрать уже как RAID10 не перезагружая ОС. Алгоритм был примерно следующим:

  • извлек один из четырех дисков из массива
  • добавил в группу томов как отдельное устройство
  • перенес все экстенты на него
  • извлек из группы томов raid5
  • разобрал на диски
  • собрал из них raid10, с пропуском одного диска
  • добавил в группу томов
  • перенес экстенты обратно
  • извлек отдельный диск
  • добавил его в массив на место недостающего
  • FROFIT =)
    Все операции проводились удаленно, по ssh. Вот за такую простоту и гибкость использую lvm повсеместно и в производстве и на персональных машинах.
#7

Очень интересно… Я, когда UNIX изучал, lvm/mdadm ещё не написали)) С тех пор так руки и не дошли пощупать - всегда находится что-нибудь поважнее. Linux для меня хобби, а не работа, поэтому я позволяю себе иметь пробелы в образовании))) У меня было впечатление (вероятно, кстати, ошибочное), что lvm привносит overhead в работу с диском. При этом возможность подвинуть раздел лёгким движением руки, да ещё без опаски за данные, дорогого стоит.
По поводу data=journal читал очень интересное мнение (причём в нескольких местах), что при активном чтении только что записанных страниц (что может быть актуально как раз для десктопа или СУБД), этот режим может оказаться даже быстрее, особенно если журнал вынесен на SSD. Сам ещё не пробовал, хотя на моей конфигурации - дело нескольких минут.

А почему nodealloc, кстати?

#8

С журналом на отдельном устройстве не экспериментировал - обычно кроме основного дискового массива, в моих системах дополнительного диска нет. Если нужно сделать упор на скорость - просто собираю не raid5, а raid10.
Отложенное выделение блоков отключил для спокойствия, ибо я не знаю механизм его работы настолько, что бы быть уверенным, что никакого дополнительного кэширования/буферизации в систему он не привнесет, и как следствие не нарушит целостность ФС, при сбое питания или зависании, а на производительность в режиме data=ordered оно практически не влияет, насколько я помню, речь о нескольких процентах.

Mastodon Mastodon