freebsd stable - Feb 2010 - one more load-cycle-count problem

Hi all,

After being disturbed by the firmware issues of the wd drives causing
exceeding load cycles (see thread "immense delayed write to file system
(ZFS and UFS2), performance issues" in January), I have found some more
problematic drives in the following setup:

4 x 2.5" WDC WD4000BEVT-00ZAT0 in RAIDZ1 configuration attached to a
Supermicro SAS controller:

mpt0@pci0:2:0:0:        class=0x010000 card=0xa38015d9 chip=0x00581000
rev=0x08 hdr=0x00 vendor     = 'LSI Logic (Was: Symbios Logic, NCR)'
    device     = 'SAS 3000 series, 8-port with 1068E -StorPort'
    class      = mass storage
    subclass   = SCSI

luna# camcontrol devlist
<ATA WDC WD4000BEVT-0 1A01>        at scbus0 target 0 lun 0 (pass0,da0)
<ATA WDC WD4000BEVT-0 1A01>        at scbus0 target 1 lun 0 (pass1,da1)
<ATA WDC WD4000BEVT-0 1A01>        at scbus0 target 2 lun 0 (pass2,da2)
<ATA WDC WD4000BEVT-0 1A01>        at scbus0 target 3 lun 0 (pass3,da3)


The disks appear to load/unload every 10s or so if I do not artificially
keep them busy. Does anyone here have a suggestion how to make this
interval longer or even turn off the unload feature completely?

I tried

luna# camcontrol idle da0 -t 600
(pass0:mpt0:0:0:0): CMD: IDLE: e3 00 00 00 00 40 00 00 00 00 78 00
(pass0:mpt0:0:0:0): CAM Status: CCB request was invalid

luna# camcontrol standby da0 -t 600
(pass0:mpt0:0:0:0): CMD: STANDBY: e2 00 00 00 00 40 00 00 00 00 78 00
(pass0:mpt0:0:0:0): CAM Status: CCB request was invalid

>From /usr/share/misc/scsi_modes I gather that page 26 should contain power
control features, but no avail:

luna# camcontrol modepage da0 -m 26
camcontrol: error sending mode sense command


Any further ideas how to get rid of this "feature"?


cu
  Gerrit

>Any further ideas how to get rid of this "feature"?
You have several options.

1) The most "clean" solution is probably using the WDIDLE3 utility on
your drives to disable automatic parking or in cases where its not
possible to complete disable it, you can adjust it to 5 minutes, which
essentially solves the problem. Note that going this route will
probably involve rebuilding your entire array from scratch, because
applying WDIDLE3 to the disk is likely to very slightly affect disk
geometry, but just enough for hardware raid or ZFS or whatever to bark
at you and refuse to continue using the drive in an existing pool (the
affected disk can become very slightly smaller in capacity). Backup
data, apply WDIDLE3 to all disks. Recreate the pool, restore backups.
This will also void your warranty if used on the new WD drives,
although it will still work just fine.

2) A less clean solution would be to setup a script that polls the
SMART data of all disks affected by the problem every 8-9 seconds and
have this script launch on boot. This will keep the affected drives
just busy enough to not park their heads.


- Sincerely,
Dan Naumov