Re: Is TRIM/DISCARD going to be a performance problem?

[Chris Mason <chris.mason@oracle.com>]

On Mon, 2009-05-11 at 04:41 -0400, Theodore Tso wrote: 
> On Mon, May 11, 2009 at 10:12:16AM +0200, Jens Axboe wrote:
> > 
> > I largely agree with this. I think that trims should be queued and
> > postponed until the drive is largely idle. I don't want to put this IO
> > tracking in the block layer though, it's going to slow down our iops
> > rates for writes. Providing the functionality in the block layer does
> > make sense though, since it sits between that and the fs anyway. So just
> > not part of the generic IO path, but a set of helpers on the side.
> 
> Yes, I agree.  However, in that case, we need two things from the
> block I/O path.  (A) The discard management layer needs a way of
> knowing that the block device has become idle, and (B) ideally there
> should be a more efficient method for sending trim requests to the I/O
> submission path.

Just a quick me too on the performance problem.  The way btrfs does
trims today is going to be pretty slow as well.

For both btrfs and lvm, the filesystem is going to maintain free block
information based on logical block numbers.  The generic trim layer
should probably be based on a logical address that is stored per-bdi.

Then the bdi will need a callback to turn the logical address based trim
extent into physical extents on N number of physical device.

The tricky part is how will the FS decide a given block is actually
reusable.  We'll need a call back into the FS that indicates trim is
complete on a given logical extent.

-chris
>