Re: libata default FUA support

[Robert Hancock <hancockrwd@gmail.com>]

On 03/01/2011 02:33 PM, Markus Trippelsdorf wrote:
> FUA support is currently switched off by default in
> drivers/ata/libata-core.c.
> Given that many modern drives do support FUA now, wouldn't it make sense
> to switch it on without setting a (undocumented) kernel/module
> parameter?

I believe I proposed this some time ago. Essentially all modern drives 
should support FUA now, since it's part of the definition of the NCQ 
(FPDMA) read/write commands. However, as I recall one of the objections 
to enabling it was that since it's just a bit in a command, there's a 
possibility that some drives may ignore it by accident or design, which 
is less likely with an explicit cache flush command. I'm not very 
inclined to agree myself (if you go down that road of pre-emptively 
predicting drive implementer stupidity, where do you stop?) but that's 
what was raised.

Another complication is that NCQ can be disabled at runtime either by 
user request or by error-handling fallback, and not all drives that 
support NCQ also support the FUA versions of the non-NCQ read/write 
commands, so changes in NCQ enable status may also need to result in 
changes in FUA support status on the block device.

I believe the way the block layer uses it, basically it only saves the 
overhead of one transaction to the drive. It might be significant on 
some workloads (especially on high IOPS drives like SSDs) but it's 
likely not a huge deal.