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

## svenc

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:

```
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

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

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

```
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:

```
/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

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.

----------

