Re: xfs: add FITRIM support

From: Dave Chinner <david@fromorbit.com>
To: Lukas Czerner <lczerner@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com
Subject: Re: xfs: add FITRIM support
Date: Tue, 4 Jan 2011 10:25:14 +1100	[thread overview]
Message-ID: <20110103232514.GF15179@dastard> (raw)
In-Reply-To: <alpine.LFD.2.00.1101031152101.2815@dhcp-lab-213.englab.brq.redhat.com>

On Mon, Jan 03, 2011 at 11:57:23AM +0100, Lukas Czerner wrote:
> On Thu, 30 Dec 2010, Christoph Hellwig wrote:
> 
> > On Thu, Dec 23, 2010 at 12:44:09PM +1100, Dave Chinner wrote:
> > > Hmmmm - if we are given a range to trim, wouldn't we do better to
> > > walk the by-bno btree instead?  i.e, we have two different cases
> > > here - trim an entire AG, and trim part of an AG given by {start, end}. 
> > > 
> > > We only need these range checks on the AGs that are only partially
> > > trimmed, and it would seem more efficient to me to walk the by-bno
> > > tree for those rather than walk the by-size tree trying to find
> > > range matches.
> > 
> > It might be, but I'm not sure it's really worth the complexity.  I can't
> > really find any good use case for a partially trim anyway.
> > 
> > Ccing Lukas to figure out what his intent with this was.
> 
> Hi, I assume that you're talking about situation, when you call FITRIM
> with start and len not covering the whole filesystem possibly resulting
> in trimming just a part of the AG ? In this case I just copy my answer
> from previous mail...

Yes.

> I had two reasons to do this as it is, but only one is really worth it.
> Since we want to run FITRIM from the userspace on the background, we want
> to disturb other IO as little as possible and whole filesystem trim can
> take minutes on some devices (not talking about LUNs which is even more
> painful).

Right - it's the high end we have to worry about for XFS: how long do you
expect a 100TB filesystem to take to TRIM? ;)

>
> So you'll probably agree that we do not want to have possibly
> minute long stalls when doing FITRIM. And presumably we do not want the
> users to care about the size of AG, nor the blocksize (preferably).

The issue is that an AG can cover 1TB of disk space, and locking it
for the entire time it takes to trim the free space will cause
IO disturbances. Even holding the AGF locked for a few seconds
can cause problems.

So I guess the question is what sort of ranged woul dwe be expecting
to see a userspace background trim daemon be using?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs