Диски WD Caviar Green c 4 кб сектором

Автор: | 05.01.2011

Печальный опыт использования дисков серии Caviar Green, с виду очень привлекательных — большой объём, тихие в работе, холодные, обещают экономию электроэнергии (потому и Green) — практически идеальный диск для домашнего хранилища файлов. Но не всё так гладко, как хотелось бы. Данные диски могут нормально работать, без пляски с бубном, только под управлением Windows (и то для XP надо выполнить обряд посвящения) и по их прямому назначению — хранение файлов не в составе Raid-массива. Естественно, заранее документацию по диску я не удосужился прочитать 🙁

Основной источник проблемы № 1 — это использование секторов размером 4 кб — технология Advanced Format. При этом диск рапортует «наружу» об использовании секторов размеров в 512 байт для совместимости с (не скажу какой ОС) и такое поведение никак нельзя изменить. Казалось бы, что тут такого? А проблема в том, что если не сделать правильное выравнивание разделов или при использовании файловых систем с переменным размером собственного блока начинаются тормоза в работе — при попытки изменения, к примеру, 3 кб информации, диск считает 2 своих физических сектора, изменит информацию и вновь запишет 2 сектора вместо 1.

При использовании таких дисков (у меня были 3 шт. WD15EARS — 1.5 Тб, 64 Мб кеш) в составе пула ZFS столкнулся с дикими тормозами при записи файлов — скорость была невозможно низкой — 3-5 Мб/с, в редких случаях доходила до 10 Мб/с, скорость чтения относительно приемлемой, но всё-равно низкой — не более 50 Мб/с.

Первое, что я решил попробовать — пересобрать пул сделав правильное смещение разделов (кратное 4 кб), как сам же и советовал. Было до:

# gpart show ad5
=>        34  2930277101  ad5  GPT  (1.4T)
          34         128    1  freebsd-boot  (64K)
         162     2097152    2  freebsd-swap  (1.0G)
     2097314  2928179821    3  freebsd-zfs  (1.4T)

Стало после:

# gpart show ad5
=>        34  2930277101  ad4  GPT  (1.4T)
          34           6       - free -  (3.0K)
          40         128    1  freebsd-boot  (64K)
         168     2097152    2  freebsd-swap  (1.0G)
     2097320  2928179812    3  freebsd-zfs  (1.4T)
  2930277132           3       - free -  (1.5K)

Помогло улучшить только скорость чтения, а запись по прежнему оставляла желать лучшего. Самое интересное, что в самой WD знают о желании их клиентов получить прошивку для перевода диска в нормальный режим, чтобы рапортовал о реальном размере собственного сектора, но не сильно торопятся исполнять это желание.

Помощь пришла со стороны GEOM класса geom_nop. На этот раз я решил использовать пул из этих дисков для хранения контента, к которому редко обращаются (см. ниже вторую проблему). Относительно элегантное решение нашлось на форуме FreeBSD. (Там же было упоминание небольшого патча на ядро, но так же есть упоминание о том, что созданный без патча пул оказался разрушенным и не восстановился даже после отката патча — тут следует быть осторожным.) Процедура простая:

# gnop create -S 4096 ad5
# gnop create -S 4096 ad7
# zpool create tank mirror /dev/ad5.nop /dev/ad7.nop
# zdb
tank
    version=14
    name='tank'
    state=0
    txg=4
    pool_guid=6742820377694040729
    hostid=342896741
    hostname='host.example.ru'
    vdev_tree
        type='root'
        id=0
        guid=6742820377694040729
        children[0]
                type='mirror'
                id=0
                guid=14133829431308410889
                metaslab_array=24
                metaslab_shift=33
                ashift=12
                asize=1500297035776
                is_log=0
                children[0]
                        type='disk'
                        id=0
                        guid=15241699523102049538
                        path='/dev/ad5.nop'
                        whole_disk=0
                children[1]
                        type='disk'
                        id=1
                        guid=10849963227481271978
                        path='/dev/ad7.nop'
                        whole_disk=0

После чего перезагружаемся и в пуле остаются только устройства /dev/ad5 и /dev/ad7 (без .nop), но это не важно, т.к. ZFS работает по guid дисков и нам нужно другое — параметр ashift, который после перезагрузки остаётся равным 12, что соответствует блоку записи в 4 кб.

Скорость записи при копировании с диска на диск (по данным mc) выросла примерно в 10 раз и стала 45-50 Мб/с — меня это вполне устраивает, т.к. с данного пула будут больше читать. В синтетическом тесте через dd скорость записи/чтения составила около 70 Мб/с и 150 Мб/с соответственно.

Вывод из этого простой: по возможности не использовать данные диски не для чего, кроме хранения коллекции фильмов/музыки на домашнем компьютере под управлением Windows, иначе проблемы обеспечены. В то же время, диски других производителей (Seagate, Samsung, Toshiba) умеют нормально представляться дисками с 4 кб сектором и с ними таких проблем не возникает.

Проблема №2 оказалось весьма неожиданной и на мой взгляд глупой. Глупой в том смысле, что не надо было так делать WD, по крайней мере не с такими параметрами. Суть её в ещё одной «лишней» технологии — IntelliPark, благодаря которой после 8(!) секунд бездействия головки диска паркуются.

# smartctl -a /dev/ad5 | grep 193
193 Load_Cycle_Count        0x0032   180   180   000    Old_age   Always       -       60809

60 тысяч парковок диска! На втором диске ситуация ещё хуже:

# smartctl -a /dev/ad7 | grep 193
193 Load_Cycle_Count        0x0032   171   171   000    Old_age   Always       -       88684

Почти 90 тысяч и это менее чем за 6000 часов, т.е. в среднем 15 парковок в час. Для сравнения, за почти такое же время работы диск из другой серии сделал всего 35 парковок (не тысяч, а просто 35). И это не предел — при определённых обстоятельствах, например, при использовании отложенной записи, количество парковок может быть просто диким, как и тормоза от них.

Рекомендации от производителя — wdc.custhelp.com — ещё раз показали, что на клиентов им как-то всё равно. В общем, эта серия заставила меня сильно разочароваться в дисках от WD, вдобавок к этому у меня полностью умерла пятисотка за 10 месяцев работы.

Спасла утилита wdidle3, с помощью которой я изменил дико низкие 8 секунд на 5 минут. Скачать её можно с сайта WD, но прямой ссылки не даю, т.к. моего диска там не было в списке совместимости и все действия я выполнял на свой страх и риск.

Из-за этой технологии диск полностью непригоден для использования в качестве системного или хранения файлов, к которым часто обращаются (например, файловый сервер в небольшой конторе). Его назначение — исключительно хранение больших объёмов информации, к которым не требуется частый доступ и только это. Так же, в совокупности с первой проблемой, диски данной серии не стоит использовать в составе Raid-5 или подобных конфигураций.

UPD Прямая ссылка на wdidle3.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *