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
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Sergei Shtylyov]

Hello.

Post by Michael Tokarev
On each and every machine out there, and on every dmesg
output posted on numerous mailinglists, I see messages
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...

Post by Michael Tokarev
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.

Post by Michael Tokarev
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.

Post by Michael Tokarev
Thanks.
/mjt

MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Sergei Shtylyov]

Hello, I wrote.

Post by Sergei Shtylyov

Post by Michael Tokarev
On each and every machine out there, and on every dmesg
output posted on numerous mailinglists, I see messages
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.

Post by Sergei Shtylyov

Post by Michael Tokarev
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.

Post by Sergei Shtylyov

Post by Michael Tokarev
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.

Post by Sergei Shtylyov

Post by Michael Tokarev
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.

Post by Sergei Shtylyov

Post by Michael Tokarev
Thanks.
/mjt

MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Tejun Heo]

Post by Sergei Shtylyov

Post by Sergei Shtylyov

Post by Michael Tokarev
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.

Post by Sergei Shtylyov

Post by Sergei Shtylyov

Post by Michael Tokarev
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.