Debian Squeeze: Переезд на SSD
Поддался на провокацию заманчивые результаты тестов (желающий да погуглит) и взял себе вот такой SSD под систему:
Небольшой мануал по переезду и впечатления под катом.
Параметры сего девайса:
Объем: 32Гб (Семерка в пролете, но линуксу за глаза и уши)
Кэш: 64Мб
Поддержка TRIM
Время поиска: < .1ms
Форм-фактор 2.5"
Размеры: 99.8 x 69.63 x 9.3mm
Вес: 81g
Рабочая температура: 0°C ~ 70°C
Потребление: Idle: 375mW Active: 1000mW
Вибрация: 20G. Peak, 10 ~ 20KHz
Перегрузки до 1500G (это как? оО)
RAID Support
Совместимость Windows XP, Vista, 7, Mac OS X и Linux
MTBF: 1.5 миллиона часов
Гарантия: 2 года (ДНС дал три оО)
Имеем:
root@snake-debian:/# uname -a
Linux snake-debian 2.6.32-5-686-bigmem #1 SMP Wed May 18 07:33:52 UTC 2011 i686 GNU/Linux
В качестве файловой системы использовал ext4
В системе установлено 4Гб оперативки, все они видятся системой (ядро bigmem какбэ намекает)
Итак, приступим. Создаем раздел (желательно один на весь диск). Я использовал гномовскую “Дисковую утилиту”, у кого нет иксов или есть борода можно через консоль:
root@snake-debian:/# sfdisk /dev/sdb
root@snake-debian:/# mkfs.ext4 -L ONYX /dev/sdb1
Затем устанавливаем rsync
root@snake-debian:/# aptitude install rsync
На сервере я бы посоветовал остановить все возможные сервсиы – apache, exim, syslog и т.д. На домашней машине это не актуально.
Поэтому, монтируем наш свежеотформатированный диск и копируем на него систему:
root@snake-debian:/# mkdir /mnt/ssd && mount /dev/sdb1 /mnt/ssd
root@snake-debian:/# rsync -avrt / /mnt/ssd/
Устанавливаем загрузчик:
root@snake-debian:/# echo "(hd0) /dev/sdb" | tee /mnt/ssd/boot/grub/device.map
root@snake-debian:/# grub-install --root-directory=/mnt/ssd --no-floppy /dev/sdb
root@snake-debian:/# echo "(hd0) /dev/sda" | tee /mnt/ssd/boot/grub/device.map
Далее хорошо бы привычным движением отредактировать /boot/grub/menu.lst… Щаз. В Squeeze стоит по умолчанию Grub v2. Мануал по настройке можно найти вот тут. Полезное, к слову, чтиво. У меня получилось что-то вроде этого:
root@snake-debian:/# nano /mnt/ssd/etc/grub.d/40_custom
menuentry "Debian, Linux 2.6.32-5-686-bigmem SSD" {
recordfail=1
if [ -n ${have_grubenv} ]; then save_env recordfail; fi
set quiet=1
insmod ext2
set root=(hd1,0)
search --no-floppy /dev/sdb
linux /boot/vmlinuz-2.6.32-5-686-bigmem root=LABEL=ROOT rootflags=data=writeback ro quiet splash
initrd /boot/initrd.img-2.6.32-5-686-bigmem
}
Обновляем загрузчик:
root@snake-debian:/# update-grub
Настраиваем перезагрузку системы через минуту в случае паники:
root@snake-debian:/# echo "kernel.panic = 60" >> /mnt/ssd/etc/sysctl.d/panic.conf
Крутим sysctl. Добавляем в /etc/sysctl.d/ssd.conf:
# configure settings in /proc/sys/vm/*
# агрессивность использования swap
vm.swappiness = 0
# как часто ядро должно находить незаписанные в ФС данные и писать их
vm.dirty_writeback_centisecs = 6000
# сколько времени должно пройти, чтобы ядро посчитало незаписанные в ФС данные достаточно устаревшими для их записи
vm.dirty_expire_centisecs = 6000
# сколько процентов памяти могут занимать незаписанные в ФС данные
vm.dirty_ratio = 80
# если незаписанные данные занимают меньше памяти в процентах, то их можно не записывать сейчас
vm.dirty_background_ratio = 20
Меняем /mnt/ssd/etc/fstab строку монтирования корневой ФС, отключаем swap и добавляем опции монтирования (опция commit=x включает режим обновления журнала каждые x секунд вместо 5 по-умолчанию):
...
LABEL=ROOT / ext3 noatime,nodiratime,data=writeback,commit=50,rw,suid,dev,exec,auto,nouser,async,errors=remount-ro 0 1
Не забываем закомментировать все остальное и убрать своп.
Выносим в оперативку (у нас ведь ее много, да?) весь мусор, который, по хорошему, все равно должен чиститься при каждом ребуте
...
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0
tmpfs /var/lock tmpfs defaults 0 0
tmpfs /var/spool/postfix tmpfs defaults 0 0
Некоторые еще советуют отключить syslog. На домашней машине может еще и оправдано, но я в этом сильно сомневаюсь. Поэтому, по возможности, лучше вынести /var/log на отдельный, “нормальный” жесткий, чтобы все логи писались туда. Или воспользоваться rsyslog.
На этом все. Перезагружаемся, выбираем в качестве варианта загрузки вариант с SSD и смотрим. У меня система стала грузиться раза в два быстрей, офисные приложения открываются практически мгновенно, фаерфокс с парой десятков вкладок стартует за 3-5 секунд. Синтетику не делал – ибо зачем? Тестов дофига, желающие погуглят, а мне они до лампочки – я ведь ничего целыми днями не архивирую. Но скорость работы понравилась. Думалось зафигачить его сразу в ноут, но уж больно размер маловат. Так что пусть пока живет в “большой” машине =)
В ноут я себе поставил OCZ vertex 2 на 90 гб – вполне себе хватает и цена нормальная.
От себя хотелось бы добавить, что ssd есть смысл форматировать в btrfs и запускать с опцией -o ssd, если ставите новую систему – на десктопе всё же разница ощутима между ext4 и btrfs. Правда, я сейчас сижу на ext4 – фс в один прекрасный момент осыпалась.
Ещё не советую брать интеловские SSD – если процессор не core i5/i7 – то это бесполезная трата денег. Выше вертекса на обычных задачах прыгнуть пока что нельзя, а на дисковых операциях c2d с интелом G3 выкушивается легко и непринужденно. Ну да, круто конечно, что у вас фильм в RAM улетает за 15 секунд… но так ли оно надо, если процессор в это время похрюкивает ядром с 100% wa на это ядро….
btrfs это конечно хорошо и правильно, наверное, но как-то не debian-way. В смысле, поработает годик в продакшене – тогда пожалуйста. А огребать вместо рабочей машины поле для экспериментов за свои же деньги как-то не хочется.
Интеловые брать пока не собираюсь – не домой по крайней мере, хотя в серваке стоят и ни жу-жу. Все-таки цена кусается. А вот что-нибудь второго поколения (или какого там уже?), со скоростью записи мегабайт под 170… это будет интересно =)
“Поддержка TRIM”
А толку от него, если поддержка TRIM начинается только с версии ядра 2.6.33. А когда Debian Stable перейдёт на эту версию неизвестно :(.
А у вас сервер? Или десктоп?