linux-kernel - Re: TRIM/UNMAP/DISCARD via ATA Passthrough

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 16 Sep 2016 09:21:44 -0700
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     "Austin S. Hemmelgarn" <ahferroin7@...il.com>,
        Hannes Reinecke <hare@...e.de>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>
Cc:     linux-scsi@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: TRIM/UNMAP/DISCARD via ATA Passthrough

On Fri, 2016-09-16 at 11:53 -0400, Austin S. Hemmelgarn wrote:
> On 2016-09-16 07:16, Hannes Reinecke wrote:
> > On 09/15/2016 10:52 PM, Jason A. Donenfeld wrote:
> > > Hi Martin,
> > > 
> > > On Thu, Sep 15, 2016 at 6:07 PM, Martin K. Petersen
> > > > But how do they signal that ATA passthrough is possible? Is 
> > > > there an ATA Information VPD page? Is REPORT SUPPORTED 
> > > > OPERATION CODES supported?
> > > > 
> > > > We need really solid discovery data before we can entertain 
> > > > enabling something like this.
> > > 
> > > `sg_opcodes` said invalid request, so I think there isn't REPORT
> > > SUPPORTED OPERATION CODES, and `sg_vpd -p ai` came up illegal
> > > too.
> > > 
> > > However, sg_sat_identify worked reliably, which means a solid way 
> > > of probing this would be to send IDENTIFY DEVICE ATA via 
> > > SG_ATA_16 or SG_ATA_12.
> > > 
> > > Let me know and I can give you access to the hardware if you're
> > > curious.
> > > 
> > Sadly, that's not sufficient.
> > linux is not the only provider of an SATL (mpt3sas being the most
> > prominent other one).
> > And while they might support ATA_12/ATA_16, there is no indication 
> > that you can pass DSM TRIM that way.
> So it's better to not support it at all than to support it on 
> hardware we can reliably identify?
> 
> I get that having feature parity is a good thing, but the discussion 
> isn't about providing support for all SATL devices, it's specifically
> about UAS connected SATL devices.  Last I checked, mpt3sas doesn't do
> anything with UAS, which means it's kind of irrelevant WRT supporting
> this for UAS devices.

We're getting a bit off topic on mptsas and it's eccentric SATL.

The point is, you're asking for UAS devices which each have an internal
SATL which you say potentially doesn't support discard.  The three
problems we have are

   1. How do we identify if the UAS SATL doesn't support discard.  If it
      does, we really don't want to cause further SATL related issues by
      bypassing it, so we need a way of telling this.
   2. If the SATL doesn't support discard, will it reliably support the
      ATA_12 or ATA_16 pass through (and which one) .. we need a way of
      checking this because there are known SATLs that don't do pass
      through.
   3. How do we actually configure it?  Presumably if the SATL doesn't
      support discard, it also doesn't give us the useful mode page
      indications we use to configure TRIM, so we're going to have to do
      some pass through discovery as well.

James