Perhaps no one else is using XFS as a root filesystem on SATA drives,
but I've been giving it a go. And I've been lucky to NOT experience a
power failure in my machine room, I guess.
I've tried blktool and sdparm, both RPMS and compiled locally, but
nothing can turn off the write cache. I'm using multiple motherboards,
different drive manufactureres, but no avail.
Has anyone had success with this issue? Am I forced to continue on with
PATA drives for the foreseeable future?
Any informed responses would be a huge help.
Details:
Tyan mobo, Opteron, 2.6.12-1.1398_FC4smp, x86_64, WDC WD800JD-00LS SATA
drive
modules:
sata_sil 15301 4
libata 58825 1 sata_sil
sd_mod 25153 6
scsi_mod 167417 2 libata,sd_mod
nForce4 mobo, Athlon64 X2, 2.6.15-1.1831_FC4smp, x86_64, ST380817AS SATA
drive
modules:
libata 98265 1 sata_nv
sd_mod 53697 2
scsi_mod 195321 2 libata,sd_mod
Christian Rice wrote:
We all know that disabling write cache on drives with no battery
backup is a good thing, and we all know how to do it on your average
IDE drive (hdparm -W0 /dev/hda).
But what about on SATA disks? I've found sdparm, which has settings
for disabling write cache on SCSI disks (and supposedly SATA disks
that use the SCSI device (eg, /dev/sda). It simply doesn't work, though:
[root@sqld xian]# sdparm --set WCE=1 /dev/sda
/dev/sda: ATA Maxtor 7Y250M0 YAR5
change_mode_page: failed setting page: Caching (SBC)
[root@sqld xian]# uname -r
2.6.14-1.1656_FC4smp
Of course I'm using XFS...
The sdparm web page suggests some SCSI commands will be better
implemented in kernel 2.6.15.
The only other thing I might try here is to recompile a 64-bit version
of sdparm, as I downloaded/installed version .96 i386, but this system
is a dual-proc Opteron running 64-bit FC4.
Anyone have any other ideas?
On Mon, Jan 30, 2006 at 12:19:51PM -0800, Christian Rice wrote:
We all know that disabling write cache on drives with no battery backup
is a good thing, and we all know how to do it on your average IDE drive
(hdparm -W0 /dev/hda).
But what about on SATA disks?
Is blktool the New(tm) way to do this?
-- Russell Howe | Why be just another cog in the machine,
rhowe@xxxxxxxxxxxx | when you can be the spanner in the works?
|