[Top] [All Lists]

Re: [RFC PATCH 4/4] xfs: add background scanning to clear EOFBLOCKS inod

To: Brian Foster <bfoster@xxxxxxxxxx>
Subject: Re: [RFC PATCH 4/4] xfs: add background scanning to clear EOFBLOCKS inodes
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 5 Sep 2012 17:00:11 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <50460BF1.3070100@xxxxxxxxxx>
References: <1346097111-4476-1-git-send-email-bfoster@xxxxxxxxxx> <1346097111-4476-5-git-send-email-bfoster@xxxxxxxxxx> <20120903052842.GT15292@dastard> <50460BF1.3070100@xxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Sep 04, 2012 at 10:10:57AM -0400, Brian Foster wrote:
> On 09/03/2012 01:28 AM, Dave Chinner wrote:
> > On Mon, Aug 27, 2012 at 03:51:51PM -0400, Brian Foster wrote:
> >> Create a delayed_work to enable background scanning and freeing
> >> of EOFBLOCKS inodes. The scanner kicks in once speculative
> >> preallocation occurs and stops requeueing itself when no EOFBLOCKS
> >> inodes exist.
> >>
> >> Scans are queued on the existing syncd workqueue and the interval
> >> is tied to the syncd interval, which is a default of 30s. The
> >> minimum file size for a background scan is hardcoded to 100MB.
> > 
> > I'd set it to be much longer than the xfs_syncd_centisecs period.
> > The data may not be written back for a long while, and a file that
> > is open, written and closed repeatedly (NFS write patterns for large
> > and/or slowly written files) should not have it's preallocation
> > truncated every 30s.
> > 
> > I'd suggest that a 5 minute sweep is probably sufficiently frequent
> > to avoid most fragmentation issues and long term buildup of speculative
> > preallocation whilst not perturbing large/slow writers too much....
> > 
> Any thoughts on having tunables for both values (time and min size?) on
> the background scanning?

Well, my suggestion for timing is as per above (xfs_syncd_centisecs
* 100), but I don't really have any good rule of thumb for the
minimum size. What threshold do people start to notice this?

I'd SWAG that something like 32MB is a good size to start at because
most IO subsystems will still be able to reach full bandwidth with
extents of this size when reading files.

Alternatively, if you can determine if the inode is still in use at
the time of the scan (e.g. elevated reference count due to an open
fd) and skip the truncation for those inodes, then a minimum size is
not really needed, right?


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>