Data integrity on serial ATA disk drives

I've seen a lot of switching over from IDE disks to serial ATA disks. In
fact, an Intel blade server we want to purchase does not have any choice.
The question I have not been able to answer is, "Do they provide the special
services that high reliability systems need?"

What I mean by that is that, for instance, an Oracle RDBMS needs to know
when data is safely placed on magnetic media, and not just in some cache in
the os or on a disk drive. I know a way to bypass the os cache in Windows
in order to guarantee my data is safe. If the disk drive says, "OK, I'm
done", but the data is still in a memory cache, then it is vulnerable to
power outages. I know you might say, "Get an UPS", but we had a massive UPS
for a building break on us just last month.

Because this is not the typical requirement of a home user, I don't know if
any attention has been paid to this by the SATA people.


Any comments are appreciated,


Robert Kindred

Robert Kindred wrote:
I've seen a lot of switching over from IDE disks to serial ATA disks. In
fact, an Intel blade server we want to purchase does not have any choice.
The question I have not been able to answer is, "Do they provide the special
services that high reliability systems need?"

Well, they almost certainly provide at least as much support for such as
IDE disks do: did you mean 'SCSI or FC' rather than 'IDE' above?


What I mean by that is that, for instance, an Oracle RDBMS needs to know
when data is safely placed on magnetic media, and not just in some cache in
the os or on a disk drive. I know a way to bypass the os cache in Windows
in order to guarantee my data is safe.

I believe that applies to IDE (and I assume SATA, though I haven't tried
it) as well as to SCSI. However, I've heard that some IDE drives may
simply ignore the 'turn off write-caching' command and keep doing it
behind the scenes, so checking would seem prudent (doing a series of
small sequential writes with both write-caching and queuing disabled
should make it obvious whether the disk is taking a full rotation to
complete each of them).

If the disk drive says, "OK, I'm
done", but the data is still in a memory cache, then it is vulnerable to
power outages. I know you might say, "Get an UPS", but we had a massive UPS
for a building break on us just last month.

A possibility of which far too many people don't seem to be properly
aware. I've sometimes wondered whether two stages of UPS (say, one for
the entire room and another for each machine in it) would effectively
eliminate the problem (as long as both were of high quality).


Because this is not the typical requirement of a home user, I don't know if
any attention has been paid to this by the SATA people.

Both the IDE and SATA command sets include instructions to disable
on-disk write-caching. It would surprise me if any SATA drives ignored
it (and I'm not even certain that any IDE drives do - I just have this
vague recollection of having heard that, but it might just have been
that manufacturers tend to ship IDE drives with write-caching enabled).

Also, both command sets include instructions to force all cached writes
to disk if write-caching *is* enabled (which if 'forced' writes are rare
allows drives that don't support queuing at least to approximate the
write performance of disks that do) - but I wouldn't bet my business
that those commands are always honored either (especially for IDE drives).

- bill

Bill Todd wrote:
Robert Kindred wrote:

....

I know a way to bypass the
os cache in Windows in order to guarantee my data is safe.

I believe that applies to IDE (and I assume SATA, though I haven't tried
it) as well as to SCSI. However, I've heard that some IDE drives may
simply ignore the 'turn off write-caching' command and keep doing it
behind the scenes, so checking would seem prudent (doing a series of
small sequential writes with both write-caching and queuing disabled
should make it obvious whether the disk is taking a full rotation to
complete each of them).

I misread your statement above as referring to bypassing the disk cache
rather than the os cache - but from what you said later you may in fact
have meant the former anyway.

A SCSI feature which IDE drives don't implement (but which SATA may) is
the ability to specify that a particular write should be forced to disk
even when on-disk write-caching is enabled. IIRC the NT/2K/XP NTFS file
system uses this (when running on a SCSI drive) to ensure that its
metadata log is secure even when the drive's write-cache is functioning
(and databases may well do the same).

- bill

"Bill Todd" wrote in message
news:7-SdnXVIUpugfkrenZ2dnUVZ_s2dnZ2d@metrocastcablevisio n.com...
Bill Todd wrote:
Robert Kindred wrote:

...

[]

I misread your statement above as referring to bypassing the disk cache
rather than the os cache - but from what you said later you may in fact
have meant the former anyway.

Actually, I know how to get Windows to not cache, but I don't know how to
tell the disk not to do that. If there is a feature, I will have to find a
way to do it through the os.

A SCSI feature which IDE drives don't implement (but which SATA may) is
the ability to specify that a particular write should be forced to disk
even when on-disk write-caching is enabled. IIRC the NT/2K/XP NTFS file
system uses this (when running on a SCSI drive) to ensure that its
metadata log is secure even when the drive's write-cache is functioning
(and databases may well do the same).
This sounds good to me. What might be better (for me) is if I could tell
the disk to never cache writes through some manufacturer's disk utility. On
my system, this extra disk drive only contains data which must always go to
disk.

- bill

Thanks for your comments,

Robert

Robert Kindred wrote:
"Bill Todd" wrote in message
news:7-SdnXVIUpugfkrenZ2dnUVZ_s2dnZ2d@metrocastcablevisio n.com...
Bill Todd wrote:
Robert Kindred wrote:
...

[]
I misread your statement above as referring to bypassing the disk cache
rather than the os cache - but from what you said later you may in fact
have meant the former anyway.

Actually, I know how to get Windows to not cache, but I don't know how to
tell the disk not to do that. If there is a feature, I will have to find a
way to do it through the os.

Without rebooting into Win2K, my recollection is that you get to the
feature through the device property sheet for the particular disk.
Should you be running Linux, I think it's controlled by their disk
utility whose name escapes me at the moment (somethingparm?).

....

What might be better (for me) is if I could tell
the disk to never cache writes through some manufacturer's disk utility.

The only thing you'd have to worry about then would be whether the OS
would decide it knew better and turn it on again. Going through the OS
mechanism (so that it *knew* what you wanted) might be safer.

- bill

I believe that applies to IDE (and I assume SATA, though I haven't tried
it) as well as to SCSI. However, I've heard that some IDE drives may
simply ignore the 'turn off write-caching' command and keep doing it

SCSI allows to say "this particular individual write must go to the platter" -
the ForceUnitAccess bit. NTFS uses this bit for log writes.

I never heard on IDE having such a feature.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation

http://www.storagecraft.com

In article RaKdnTeHyedyfUrenZ2dnUVZ_tWdnZ2d@metrocastcablevi sion.com,
Bill Todd wrote:
Robert Kindred wrote:
I've seen a lot of switching over from IDE disks to serial ATA disks. In
fact, an Intel blade server we want to purchase does not have any choice.
The question I have not been able to answer is, "Do they provide the special
services that high reliability systems need?"

Well, they almost certainly provide at least as much support for such as
IDE disks do: did you mean 'SCSI or FC' rather than 'IDE' above?


What I mean by that is that, for instance, an Oracle RDBMS needs to know
when data is safely placed on magnetic media, and not just in some cache in
the os or on a disk drive. I know a way to bypass the os cache in Windows
in order to guarantee my data is safe.

I believe that applies to IDE (and I assume SATA, though I haven't tried
it) as well as to SCSI. However, I've heard that some IDE drives may
simply ignore the 'turn off write-caching' command and keep doing it
behind the scenes, so checking would seem prudent (doing a series of
small sequential writes with both write-caching and queuing disabled
should make it obvious whether the disk is taking a full rotation to
complete each of them).

If the disk drive says, "OK, I'm
done", but the data is still in a memory cache, then it is vulnerable to
power outages. I know you might say, "Get an UPS", but we had a massive UPS
for a building break on us just last month.

A possibility of which far too many people don't seem to be properly
aware. I've sometimes wondered whether two stages of UPS (say, one for
the entire room and another for each machine in it) would effectively
eliminate the problem (as long as both were of high quality).


You've never seen a UPS fail catastrophically and drop a system? In
my case, a mainframe. Sh*t happens.

A good server has N+1 hot-swapable power supplies. You plug the power
cable from one PSU into your UPS and the other into the AC, directly,
or if you've got a few bucks, a second UPS.
--
a d y k e s @ p a n i x . c o m

Don't blame me. I voted for Gore.

Bill Todd wrote:

Without rebooting into Win2K, my recollection is that you get to the
feature through the device property sheet for the particular disk.
Should you be running Linux, I think it's controlled by their disk
utility whose name escapes me at the moment (somethingparm?).

With Gnu/Linux use hdparm -W /dev/hdx
where hdx is hda, hdb, hdc, etc.