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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
