SSD Corsair Force Series 3 на самом деле: последние штрихи

Мне казалось, что недавней заметкой я закрыл тему 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-файлов — весьма значимо:

ssd3-filetest2-1.png

При удалении дерева портежей результаты для ext4 на обоих носителях можно считать практически равными — что тоже понятно, пропускная способность интерфейса при этом играет очень мало рояля. Но вот сравнение с btrfs на одном и том же SSD Corsair Force Seriesт 3 для последней оказывается просто катастрофическим:

ssd3-filetest2-2.png

И это при том, что в прошлом случае btrfs монтировалась с опцией ssd, каковая в первую очередь и должна была бы способствовать быстродействию на операциях удаления…В общем, можно сделать вывод, что использовать btrfs для реальной работы пока ещё рано — слишком она непредсказуема от версии к версии, обнаруживая то зияющие высоты производительности, то не менее сверкающие её провалы. Так что поживём пока на традиционной ext4, а там видно будет. Ведь чем не шутит чёрт, когда засыпают компетентные органы — вдруг решится проблема с ZFS под Linux?

И ещё один вывод из всего написанного выше: автоматика по части выравнивания разделов на SSD-накопителях в современных версиях fdisk  работает вполне исправно, и на неё можно положиться, не заморачивая себе голову ручными пассами.