Re: [PATCH 1/2] fs: Do not dispatch FITRIM through separate super_operation

[Mark Lord <kernel@teksavvy.com>]

On 10-11-19 09:06 AM, Christoph Hellwig wrote:
> On Fri, Nov 19, 2010 at 09:01:02AM -0500, Mark Lord wrote:
>> Ithink a reasonable approach would be to modify the existing interfaces
>> so that the LLD can report a "max discard ranges per command" back up
>> the stack.
>>
>> This way, libata could report a max of say, 64 ranges per "discard" (trim),
>> and DM/RAID could simply (for now) report a max of one range per discard.
>
> That's certainly the easy way out.  You'll need a good way to actually
> transport the ranges as we can't simply sote them in bi_sector/bi_size
> and adapt the whole block layer to deal with the two types of different
> discards.  Not saying it's impossible, but when I tried it before it
> wasn't pretty.

Yeah.  I think for this to happen is has to be evolutionary,
and the proposal above looks like a reasonable first crack at it.

I'm not sure about the issues on "adapting the block layer" ?
For FITRIM, the blocks being trimmed would be reserved at the fs level,
before issuing the discard for them.  So ordering through the block layer
shouldn't matter much for it.  Does that simplify things?

I see FITRIM just allocating a page to hold the ranges (for the >1 case)
and passing that page down through the layers to libata (or any other
LLD that supports >1 ranges).

??