This message is from the T13 list server.
Harlan,
>What are the benefits of FUA?
FUA is already defined for SCSI, and we currently use it. The
primary benefit that get from FUA is the ability to write system
critical data to disk without having to take the performance hit of a
full 'flush cache'.
>Do the benefits of FUA justify the risks ?
I don't consider this to be high risk as it is not a new
problem, this is solving an old problem with a known solution on a new
storage protocol. The benefit is reduced chance of data corruption
without a large performance hit. I think it is justified.
>Will drive hardware need to change ?
Yes, firmware, but as many hard drive manufacturers already have
this on their SCSI lines, it is just a port for many of them.
>Does FUA apply to Reads ?
It can. An FUA read would have to return what is on the disk
rather than what is in the cache. I believe this is defined for SCSI,
but it hasn't been defined for ATA, and I don't see a reason to add it.
Nathan
-----Original Message-----
From: Harlan Andrews [mailto:[EMAIL PROTECTED]
Sent: Friday, June 27, 2003 2:24 PM
To: Nathan Obr
Cc: [EMAIL PROTECTED]
Subject: Re: [t13] Re: hmmm.. no comments?
On Friday, June 27, 2003, at 09:13 AM, Nathan Obr wrote:
> Because the FUA commands do not affect the internal queuing or
> write ordering of the disk, FUA commands are no more of a data
> integrity
> problem for the host then normal write and queued write commands. In
> fact, FUA commands don't even affect the caching on the disk. FUA
data
> transfers can still be cached, they just can't be signaled complete
> until the command is written to disk.
I'm relieved to hear your assurance that there is no data integrity
problem. I'm still worried about adding extra complexity to the
drives and the possibility of confusion.
What are the benefits of FUA?
Do the benefits of FUA justify the risks ?
Will drive hardware need to change ?
Does FUA apply to Reads ?
...Harlan
