твердотельный ssd-накопитель: немного шаманства, пару слов о TRIM и почему btrfs «не тру»

Приветствую (^_^)

Пожалуй как всякий гик, прикупив новый девайс (Crucial C300 на Marvell 88SS9174), я вплотную занялся изучением того, что, собственно, эта недешёвая железяка может. Перенеся систему на ssd и восхитившись шустрой загрузкой (17 секунд против 41-й на 7200rmp терабайтнике от самсунг) пришло время разобраться с такой мудрёной штукой как TRIM. Так вот, вопреки распространённому мнению “Да это ж Линукс! Там всё изаропки и как нада” не всё так радужно. Ядрышко то наше собстенно TRIM то и не поддерживает. Это, оказывается, задача файловой системы! (о как, сюрприз-сорприз). Причём по дефолту оно выключено везде. Ну не разгильдяйство ли? Не верите? А вот вам тру-статья для проверки своих ssd.

Проверка, а не включён ли trim уже сейчас

Пусть /dev/sdX – наш SSD диск

1. Меняем пользователя на root:
   sudo -i
2. Пишем файл 50Мб со случайными данными:
   dd if=/dev/urandom of=tempfile count=100 bs=512k oflag=direct
3. Ищем стартовый LBA адрес у файла
   hdparm --fibmap tempfile
4. Читаем данные со стартового LBA адреса файла, замените [ADDRESS] на свой Starting LBA address из вывода предыдущей команды:
   hdparm --read-sector [ADDRESS] /dev/sdX
5. Теперь удалим временный файл и синхронизируем ФС:
   rm tempfile
sync
6. Повторяем пункт 4:
   hdparm --read-sector [ADDRESS] /dev/sdX

Если TRIM включен, то в результате вывода должны быть одни нули, если же их нет TRIM выключен.

Вот так вот, подумал я и засел читать доки. Оказывается, опция монтирования discard (включающая TRIM для файловой системы) поддерживается далеко не всеми файловыми системами. К примеру ext4 и brtfs умеют, а вот reiserfs v3 грязно ругается в логи о том что такой опции знать не знает и не работает.

А теперь плавно переходим к тому, почему brtfs не тру. Дело в том, что пару лет назад я довольно плотно исследовал вопрос “как бы это разбить диск (hdd) так, чтобы всё работало пошустрее”. Ну /boot и /home отдельным разделом это классика. А дальше? Если отформатировать корень в reiserfs это положительно скажется на скорости работы портажа, тот-же eix-sync уж очень любит reiserfs, оно и понятно: работа с тувой хучей мелкий файлов это конёк reiserfs. Однако посмотрев на скорость работы с файлами среднего размера (1-10 МБ) выясняется что ext4 торт. Да и плюшки типа экстентов это тру. В результате сих, впрочем не особо сложных размышлений, было принято решение: корень в ext4; /usr/portage/ ,как отдельный раздел, в reiserfs размером 512 МиБ (это важно, дальше всплывёт), и из /usr/portage симлинком вынести distfiles на другой раздел (файлопомойку). В результате получилось просто и элегантно: система на ext4 шустро крутится, portage работает с разделом на 512 МиБ (заполненным на 400 МиБ) в reiserfs и делает это реально быстро, да и distfiles на файлопомойке никому не мешают.

Сия идиллия продолжалась до появления ssd: раз reiserfs не умеет монтироваться с опцией discard было принято стратегическое решение “ну и фиг с тобой, сделаю раздел на гиг в ext4, делов то”. Не тут то было — знаете сколько инодов на разделе такого размера? Нет? А я знаю: явно меньше чем файлов в /usr/portage xD Он туда просто не влез. Не хватило inodes. И это несмотря на то, что размер был увеличен в 2 раза по сравнению с reiserfs где всё каком-то чудом умещалось. Почесав тыковку, вспомнил что была ещё какая-то fs без инодов (точнее с бесконечным количеством оных), уж не btrfs ли? en.wikipedia.org — она самая! уря-уря. Сношу гиговый ext4, форматирую в btrfs (зараза, пришлось ядро пересобирать), и вот оно счастье? Как бы не так. На ядре 3.0.1 оно к сожалению сыпет call stack-ами в логи тупо при чтении содержимого раздела. Ну да, experemental в ядре, но не при чтении только что созданного раздела же!!! Поимейте совесть, записав 600Мб я смог назад отчитать только 300. И получил 1,2 Гб (!!) мусора в dmesg. Ну её, такую бяку. К тому же размер тома штатно менять нельзя.

В конце концов просто перенёс /usr/portage/ на “родину”, в корневой раздел, и на этом всё. Надеюсь шустрый ssd нивелирует не шуструю ext4 при чтении туевой кучи мелких файлов. Спасибо за внимание :)

P.S. Не делайте для ext2/3/4 tune2fs -o journal_data_writeback /dev/sdaX , это хоть и выключит журнал для метаданных, но с ним выключится и TRIM.

P.P.S Чтобы прикинуть сколько данных и кто пишет на диск можно использовать что-то типа iotop -a (оставьте в фоне на пару часов), там будут строки вида [jbd2/sda2-8] — это метаданные. Так-же можно посмотреть объём записанного на ext командой tune2fs -l /dev/sda4 | grep eti

ssd Crucial C300 128Gb SATA-3

hdd WDC WD7500AAKS 750Gb SATA-2