Мне казалось, что недавней заметкой я закрыл тему SSD до появления девайсов следующего поколения. Однако два затронутых в ней вопроса — о недостаточном, против ожидания, быстродействии btrfs и связи оного с выравниванием — так и не давали мне покоя. Как, впрочем, и вообще проблема выравнивания, ясности относительно которой у меня так и не образовалось.И тут подвернулся случай вернуться к теме: после долгих экспериментов с 32-битными редакциями PCLinuxOS я в конце концов остановился на 64-разрядной версии этого дистрибутива. Что, разумеется, потребовало переустановки систему. Ну а где переустановка — там и переразметка диска. Каковую я и проделал — опять же не штатными средствами инсталлятора (то есть с помощью drakdisk’а), а, перейдя в текстовую консоль, стандартным fdisk‘ом.Не смотря на то, что я, с учётом полученного ранее опыта, несколько изменил размеры разделов, результат в целом был тот же — первый из них автоматически начинался с сектора 2048, а все последующие — округлялись до величин, кратных 8, в расчёте на размер блока в 4 Кбайт, каковым он для SSD на самом деле и является:
Device Boot Start End Blocks Id System/dev/sdd1 * 2048 1026047 512000 83 Linux/dev/sdd2 1026048 34580479 16777216 83 Linux/dev/sdd3 34580480 234441647 99930584 83 Linux
Из чего я сделал вывод, что современный fdisk — а у меня, судя по выводу
$ fdisk -vfdisk (util-linux-ng 2.18)
он был вполне современным (последняя, на данный момент, версия util-linux, вроде, — 2.20), таки выравнивает границы разделов. В чём я вскоре убедился, так как на этот раз отказался от использования btrfs (почему — скажу под занавес), выбрав устоявшуюся ext4 для всех разделов, и определил для них опции монтирования как
noatime,nodiratime,data=writeback
Теперь оставалось только повторить измерения быстродействия файловых операций, результаты чего приведены в таблице — в сравнении с таковыми для btrfs на том же носителе и с выровненной вручную ext4 на Corsair Nova Series.Таблица. Быстродействие файловых операций
| Тест | Копирование | Удаление | |||
| Объект | Flac | Portages | Avi | Iso | Portages |
| SSD SATA-III, ext4 | 2 | 16 | 33 | 4 | 2 |
| SSD SATA-III, btrfs | 4 | 19 | 34 | 7 | 15 |
| SSD SATA-II, ext4 | 2 | 44 | 61 | 8 | 3 |
Результаты оказались несколько неожиданными. То, что на всех операциях копирования ext4 на SSD SATA-III в трёх случаях из четырёх опередила свою сестрёнку на носителе со 2-й версией интерфейса, было вполне естественно — как и масштаб опережения, в среднем более чем двукратный. Но она обошла и btrfs на том же носителе — и при копировании iso-образа и flac-файлов — весьма значимо:
При удалении дерева портежей результаты для ext4 на обоих носителях можно считать практически равными — что тоже понятно, пропускная способность интерфейса при этом играет очень мало рояля. Но вот сравнение с btrfs на одном и том же SSD Corsair Force Seriesт 3 для последней оказывается просто катастрофическим:
И это при том, что в прошлом случае btrfs монтировалась с опцией ssd, каковая в первую очередь и должна была бы способствовать быстродействию на операциях удаления…В общем, можно сделать вывод, что использовать btrfs для реальной работы пока ещё рано — слишком она непредсказуема от версии к версии, обнаруживая то зияющие высоты производительности, то не менее сверкающие её провалы. Так что поживём пока на традиционной ext4, а там видно будет. Ведь чем не шутит чёрт, когда засыпают компетентные органы — вдруг решится проблема с ZFS под Linux?
И ещё один вывод из всего написанного выше: автоматика по части выравнивания разделов на SSD-накопителях в современных версиях fdisk работает вполне исправно, и на неё можно положиться, не заморачивая себе голову ручными пассами.