Re: Cannot detect SATA disk's FUA/DPO feature

[Zheng Liu <gnehzuil.liu@gmail.com>]

On Tue, Apr 10, 2012 at 09:15:07PM +0200, Stefan /*St0fF*/ Hübner wrote:
> Am 09.04.2012 10:34, schrieb Zheng Liu:
> > Hi list,
> > 
> > Recently I meet a problem in upstream kernel, which the problem is that
> > disk driver can not detect FUA/DPO feature of SATA disk.  This machine
> > has two SATA disks, one is C400-MTFDDAK256M and another is WDC
> > WD1002FAEX-0, both of them are plugged into mainboard.  I read the data
> > sheet and both of them support FUA feature.  I am not sure whether this
> > is a bug or not in kernel.  Meanwhile, I have tested in SAS disk and
> > kernel displays that the disk supports FUA feature in dmesg.
> > 
> > When we detect FUA feature for SAS disk in kernel, we will use SCSI
> > command set to detect FUA feature.  Namely, in current kernel, we use
> > FUA bit to check whether this SAS disk supports FUA feature or not.
> > However, SATA disk uses ATA command set.  So in current kernel, this
> > method doesn't detect whether or not SATA disk supports FUA feature.  Am
> > I missing something?
> > 
> > I put dmesg file in attachment.  Hopefully it is useful.
> > 
> > Regards,
> > Zheng
> 
> Hi Zheng,
> 
> as far as I read specs, libata should translate FUA stuff as described
> in the SAT spec:
> --------snip-->
> 9.17.2 WRITE commands with FUA
> This subclause applies to the translation of the WRITE (10) command,
> WRITE (12) command, and WRITE (16) command.
> If the FUA bit is set to zero in the SCSI write command CDB, then the
> SATL shall process this command as described in 9.17.1.
> If the FUA bit is set to one in the SCSI write command CDB, then the
> SATL shall send the following, in accordance with the constraints
> described in 9.1:
> a) the following ATA commands:
> 1) an ATA write command (see 3.1.26) excluding WRITE DMA FUA EXT, WRITE
> DMA QUEUED
> FUA EXT, WRITE MULTIPLE FUA EXT, and WRITE FPDMA QUEUE; and
> 2) an ATA verify command (see 3.1.24);
> b) one of the following ATA commands (see ATA8-ACS):
> A) WRITE DMA FUA EXT;
> B) WRITE DMA QUEUED FUA EXT; or
> C) WRITE MULTIPLE FUA EXT;
> or
> c) an ATA WRITE FPDMA QUEUED command (see SATA-2.6) with the FUA bit in
> the Device field set to
> one.
> <--snap-----------
> 
> so if the disks supported FUA according to their ATA_IDENTIFY_DEVICE
> data, I'd guess someone wanted to care about that part of the SATL in
> the near future ;)
> 
> Greets,
> Stefan

Hi Stefan,

Cc to linux-ide mailing list for finding more suggestions.

Thank you for your reply.  I use sa_sat_identity command to read disk
information.  The result shows that SATA disk supports WRITE DMA FUA
EXT, WRITE DMA QUEUE FUA EXT, WRITE MULTIPLE FUA EXT and WRITE FPDMA
QUEUE commands in my machine.  So, IMHO, maybe there is a defect in
upstream kernel.  I read the stuff of scsi disk driver and the calling
stack is as following:

sd_probe()
|
->sd_probe_async()
  |
  ->sd_revalidate_disk()
    |
    ->sd_read_cache_type()
      |
      ->sd_do_mode_sense()
        |
        ->scsi_mode_sense()
          |
          ->scsi_execute_req()
            |
            ->blk_execute_rq()
              |
              ->blk_execute_rq_nowait()
                |
                ->ata_scsi_queuecmd()
                  |
                  ->ata_scsi_simulate()

Until now, I don't have a conclusion about whether it is a defect in
kernel.  I will go on tracing this problem.  Have you some suggestions?
Please let me know.  Thank you.

Regards,
Zheng