Re: SATA: Is "DPO and FUA" ever supported?

[Tejun Heo <htejun@gmail.com>]

Sergei Shtylyov wrote:
>>> scsi 0:0:0:0: Direct-Access     ATA      ST3250620NS      3.AE PQ: 0
>>> ANSI: 5
>>> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
>>> SCSI device sda: write cache: enabled, read cache: enabled, doesn't
>>> support DPO or FUA
> 
>>> for SATA disk drives.  And I wonder -- are those features
>>> supported at all by linux,
> 
>    FUA is surely supported by libata.

Yeah, all the code is there but it is disabled by default.  The problem
is that some controllers can't handle FUA opcodes properly (sata_sil or
sil24 was one of them, I think) and we need to white or black list
controllers which never happened.

>>> and whenever it can be used to support DPO and/or FUA...
> 
>>    DPO and FUA bits are a part of SCSI CDB and so only affect the
>> block range specified by the command in question while FLUSH CACHE
>> [EXT] operates on the whole cache -- so, it's not equivalent.
> 
>    And yet I didn't name the reason of the non-equivalency for DPO: this
> bit effectively prohibits drive cache replacement to occur as a result
> of a command in question -- this simply has nothing to do with flushing.

DPO doesn't really affect the meaning of the operation.  FUA saves one
command during barrier sequence.  Not a bit gain but might still be useful.

FUA being pretty new on ATA land, I'm worried about firmwares which have
screwed up the implementation and doesn't really do FUA when instructed
to, which contributed to FUA support being left disabled.

-- 
tejun