SATA: Is "DPO and FUA" ever supported?

SATA: Is "DPO and FUA" ever supported?

[Michael Tokarev]

On each and every machine out there, and on every dmesg
output posted on numerous mailinglists, I see messages
similar to this:

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, and/or are there disk drives
out there which supports it as well?

For my Seagate ST3250620NS SATA drive (it's a "server" drive,
whatever it means), I can see -- at least --

           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT

reported by hdparm -I.  I wonder what "FLUSH CACHE EXT" means,
and whenever it can be used to support DPO and/or FUA...

Thanks.

/mjt

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

[Sergei Shtylyov]

Hello.

Michael Tokarev wrote:

> On each and every machine out there, and on every dmesg
> output posted on numerous mailinglists, I see messages
> similar to this:

> 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, and/or are there disk drives
> out there which supports it as well?

    Don't know, the bits have just quite recently been included into ATA spec, 
IIRC...

> For my Seagate ST3250620NS SATA drive (it's a "server" drive,
> whatever it means), I can see -- at least --

>            *    Mandatory FLUSH_CACHE
>            *    FLUSH_CACHE_EXT

> reported by hdparm -I.  I wonder what "FLUSH CACHE EXT" means,

    It reports LBA48 of a failing sector while FLUSH CACHE can only report LBA28.

> 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.

> Thanks.
> 
> /mjt

MBR, Sergei

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

[Sergei Shtylyov]

Hello, I wrote.

>> On each and every machine out there, and on every dmesg
>> output posted on numerous mailinglists, I see messages
>> similar to this:

>> 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.

>> and/or are there disk drives out there which supports it as well?

>    Don't know, the bits have just quite recently been included into ATA 
> spec, IIRC...

    FUA was introduced by ATA/PI-7.  There's no DPO support.

>> For my Seagate ST3250620NS SATA drive (it's a "server" drive,
>> whatever it means), I can see -- at least --

>>            *    Mandatory FLUSH_CACHE
>>            *    FLUSH_CACHE_EXT

>> reported by hdparm -I.  I wonder what "FLUSH CACHE EXT" means,

>    It reports LBA48 of a failing sector while FLUSH CACHE can only 
> report LBA28.

    I meant the sector which failed to be written to.

>> 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.

>> Thanks.

>> /mjt

MBR, Sergei

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

[Tejun Heo]

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