Re: Aggregating discard requests in the filesystem

[jim owens <jowens@hp.com>]

Brad Boyer wrote:
> On Mon, Nov 10, 2008 at 01:39:15PM -0700, Matthew Wilcox wrote:
>> One of the proposals in this thread (that has got buried somewhere) was
>> to expand any discard request sent down from the filesystem to encompass
>> all the adjacent free space.  I've checked with our SSD people and
>> they're fine with this idea.
>>
>> dwmw2 says "it isn't actually that hard in FAT" and then interjects some
>> personal opinion about this solution ;-)
>>
>> Is it hard in XFS?  btrfs?  ext2?  Does anyone have a problem with this
>> as a solution?
> 
> I suspect how hard it is depends somewhat on exactly what you mean by
> "all the adjacent free space" and what is expected of the file system.

My take on this is that an "expanded discard" is just saying that
any UNMAP that is sent to the device can contain blocks which were
already UNMAPed.  In fact, all blocks in the command may already
be unmapped.

The filesystem can send individual block discards down to the block
layer or/and send a range of free blocks that surround the just-freed
block(s).  It is easy as long as the trim/unmap is permitted on
an already unmapped block.  Then repeating is not an issue.

If devices do not allow unmapping an already unmapped block then
nothing works without massive filesystem changes such as Dave C
said were needed for "reliable exact tracking".

All devices must allow unmapping an already unmapped block for
the "defrag tool as unmapper" idea to work reliably too.

jim