Re: support ranges TRIM for libata

2017-03-23 Thread Martin K. Petersen
Christoph Hellwig writes: > Meh, I remember why I gave up on it - to support queued trim passthrough > we'd need to implement ATA 32 for the auxiliary fields and thus support > 32-bit CDBs. I don't really want to go there.. I wish we could stick with SATL. However, I have

Re: support ranges TRIM for libata

2017-03-23 Thread Christoph Hellwig
On Thu, Mar 23, 2017 at 03:43:30PM +0100, Christoph Hellwig wrote: > I tried this earlier before giving up on it because it looked to ugly. > But I can complete that version of it and post it for people to compare. Meh, I remember why I gave up on it - to support queued trim passthrough we'd need

Re: support ranges TRIM for libata

2017-03-23 Thread Christoph Hellwig
On Thu, Mar 23, 2017 at 11:04:58AM -0400, Tejun Heo wrote: > I kinda like the idea of sticking with satl as that's how libata has > been doing most things even if the implementation is uglier. It'd be > great to find out whether the ugliness would be acceptable or too > much. The SATL way is

Re: support ranges TRIM for libata

2017-03-23 Thread Tejun Heo
Hello, Christoph. On Thu, Mar 23, 2017 at 03:43:30PM +0100, Christoph Hellwig wrote: > > That's up to you ... from the point of view of code documenting itself, > > forming the ATA_16 TRIM in sd and not doing any satl transformation is > > easier for others to follow, but if it's going to cause

Re: support ranges TRIM for libata

2017-03-23 Thread Christoph Hellwig
On Thu, Mar 23, 2017 at 10:35:06AM -0400, James Bottomley wrote: > I'm certainly not saying we blindly follow t10, but I believe their > intent is to issue the next command from the completion of the first > (we can do this using qc->complete_fn, like atapi_request_sense). That > way we don't get

Re: support ranges TRIM for libata

2017-03-23 Thread James Bottomley
On Thu, 2017-03-23 at 14:55 +0100, Christoph Hellwig wrote: > On Thu, Mar 23, 2017 at 09:47:41AM -0400, James Bottomley wrote: > > > The current implementation already has the issue of that it does > > > corrupt user data reliably if the using SG_IO for WRITE SAME > > > commands. > > > > That

Re: support ranges TRIM for libata

2017-03-23 Thread Christoph Hellwig
On Thu, Mar 23, 2017 at 09:47:41AM -0400, James Bottomley wrote: > > The current implementation already has the issue of that it does > > corrupt user data reliably if the using SG_IO for WRITE SAME > > commands. > > That does need fixing. I don't think it's fixable as long as we translate the

Re: support ranges TRIM for libata

2017-03-23 Thread James Bottomley
On Wed, 2017-03-22 at 19:19 +0100, Christoph Hellwig wrote: > On Tue, Mar 21, 2017 at 02:59:01PM -0400, Tejun Heo wrote: > > I do like the fact that this is a lot simpler than the previous > > implementation but am not quite sure we want to deviate > > significantly from what we do for other

Re: support ranges TRIM for libata

2017-03-22 Thread Christoph Hellwig
On Tue, Mar 21, 2017 at 02:59:01PM -0400, Tejun Heo wrote: > I do like the fact that this is a lot simpler than the previous > implementation but am not quite sure we want to deviate significantly > from what we do for other commands (command translation). Is it > because fixing the existing

Re: support ranges TRIM for libata

2017-03-21 Thread Tejun Heo
Hello, On Mon, Mar 20, 2017 at 04:43:12PM -0400, Christoph Hellwig wrote: > This series implements rangeѕ discard for ATA SSDs. Compared to the > initial NVMe support there are two things that complicate the ATA > support: > > - ATA only suports 16-bit long ranges > - the whole mess of

support ranges TRIM for libata

2017-03-20 Thread Christoph Hellwig
This series implements rangeѕ discard for ATA SSDs. Compared to the initial NVMe support there are two things that complicate the ATA support: - ATA only suports 16-bit long ranges - the whole mess of generating a SCSI command first and then translating it to an ATA one. This series adds