insuring write-caching is disabled on IDE/SATA drive ?

Message

svenc · Post by **svenc** » Sun Feb 27, 2011 7:02 pm

Hi forum. I'm trying to disable write-caching on my mirrored SATA drives to prevent data integrity issues. Per the comment in the beginning of /etc/conf.d/hdparm I've modified /etc/conf.d/local.start to contain /sbin/hdparm -W0 /dev/sda... and it works except that on occasion something else accesses the drives afterwards and reverts my setting as seen below in kernel buffer:

Code: Select all

ata1.00: configured for UDMA/133
ata1: EH complete
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
ata2.00: configured for UDMA/133
ata2: EH complete
sd 1:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
usb 1-2: USB disconnect, address 2
usb 1-2: new high speed USB device using ehci_hcd and address 7
scsi4 : usb-storage 1-2:2.0
scsi 4:0:0:0: Direct-Access     SAMSUNG  SCH-I500 Card    0000 PQ: 0 ANSI: 2
sd 4:0:0:0: Attached scsi generic sg2 type 0
sd 4:0:0:0: [sdd] Attached SCSI removable disk
wlan0: direct probe to 00:21:55:b2:2b:82 (try 1)
wlan0: direct probe responded
wlan0: authenticate with 00:21:55:b2:2b:82 (try 1)
wlan0: authenticate with 00:21:55:b2:2b:82 (try 2)
wlan0: authenticated
wlan0: associate with 00:21:55:b2:2b:82 (try 1)
wlan0: associate with 00:21:55:b2:2b:82 (try 2)
wlan0: associate with 00:21:55:b2:2b:82 (try 3)
wlan0: association with 00:21:55:b2:2b:82 timed out
ata1.00: configured for UDMA/133
ata1: EH complete
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
ata2.00: configured for UDMA/133
ata2: EH complete
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
input: Logitech MX1000 mouse as /devices/pci0000:00/0000:00:1d.3/usb5/5-2/5-2.1/5-2.1:1.0/bluetooth/hci0/hci0:11/input4

Anybody know how to prevent ?

Sven

BradN · Post by **BradN** » Wed Mar 02, 2011 11:23 pm

Try renaming the hdparm binary (and in your local.start script) and see if the culprit is trying to call hdparm to change it. If hdparm is uninvolved in reconfiguring it, then it's probably some part of the kernel re-enabling it.

If hdparm is being called to re-enable it, you could replace it with a script that runs ps -Af to a log file and then find the caller program.

The write protect setting might be visible somewhere in /sys also. I'm not sure the best way to trace what might be accessing that.

svenc · Post by **svenc** » Fri Mar 04, 2011 5:28 pm

this is a neat trick, thanks for sharing. I tried it and discovered that pm-utils is also calling hdparm:

Code: Select all

root      5150     1  6 12:06 ?        00:00:00 /usr/libexec/upowerd
root      5170     1  3 12:06 ?        00:00:00 /bin/sh /usr/sbin/pm-powersave false
root      5189  5170  0 12:06 ?        00:00:00 /bin/sh /usr/lib/pm-utils/power.d/harddrive false
root      5198  5189  0 12:06 ?        00:00:00 /bin/bash /sbin/hdparm -W 1 -S 0 -B 254 -M 0 /dev/sde

trying the "hdparm -W 1 -S 0 -B 254 -M 0 /dev/sde" command at the shell reveals:

Code: Select all

/dev/sde:
 setting Advanced Power Management level to 0xfe (254)
 HDIO_DRIVE_CMD failed: Invalid argument
 setting acoustic management to 0
 HDIO_DRIVE_CMD:ACOUSTIC failed: Invalid argument
 setting drive write-caching to 1 (on)
 HDIO_DRIVE_CMD(setcache) failed: Invalid argument
 setting standby to 0 (off)
 HDIO_DRIVE_CMD(setidle) failed: Invalid argument
 HDIO_DRIVE_CMD(identify) failed: Invalid argument

this, by itself, does not seem to change write-caching on the drives in question ( sda & sdb ) so I'm still at a loss. Nevertheless I would like to disable this call of hdparm by pm-utils as I don't see the purpose, but am unable to find how to do so. qcheck reveals that nothing in pm-utils has been modified and there is a dependency by gnome-power-manager on upower which depends on pm-utils. I'll have to revisit when I have more time.

Sven

BradN · Post by **BradN** » Sat Mar 05, 2011 7:06 am

That command is trying to turn on write caching (although ineffective on sde):

setting drive write-caching to 1 (on)
HDIO_DRIVE_CMD(setcache) failed: Invalid argument

Perhaps it already ran it on sda and sdb, and the log file was later overwritten by the attempt on sde (you could make it append to the log file instead, perhaps with echoing a separator message, which should catch multiple calls).

So, probably pm-utils is what's doing it.