Печальный опыт использования дисков серии 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.