[Top] [All Lists]

Re: [PATCH v5 10/10] xfs: add background scanning to clear eofblocks ino

To: Brian Foster <bfoster@xxxxxxxxxx>
Subject: Re: [PATCH v5 10/10] xfs: add background scanning to clear eofblocks inodes
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 23 Oct 2012 12:55:46 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <1349446636-8611-11-git-send-email-bfoster@xxxxxxxxxx>
References: <1349446636-8611-1-git-send-email-bfoster@xxxxxxxxxx> <1349446636-8611-11-git-send-email-bfoster@xxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Oct 05, 2012 at 10:17:16AM -0400, Brian Foster wrote:
> Create a new mount workqueue and 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.
> The scan interval is based on the new
> 'background_prealloc_discard_period' tunable (default to 5m). The

"discard" - probably a bad idea to use a word that is associated
with similar but different functionality (i.e. mount -o discard).

Something like "speculative_prealloc_lifetime" might be a better way
of describing what it defines. i.e. speculative prealloc won't be
kept longer than this period on clean inodes. That keeps the sysctl
function independent of the underlying implementation, and it also
means we can use it as a catchall for any future speculative
allocation functionality we decide to add....

> diff --git a/fs/xfs/xfs_globals.c b/fs/xfs/xfs_globals.c
> index 76e81cf..efea30a 100644
> --- a/fs/xfs/xfs_globals.c
> +++ b/fs/xfs/xfs_globals.c
> @@ -40,4 +40,5 @@ xfs_param_t xfs_params = {
>       .rotorstep      = {     1,              1,              255     },
>       .inherit_nodfrg = {     0,              1,              1       },
>       .fstrm_timer    = {     1,              30*100,         3600*100},
> +     .eofb_timer     = {     1,              300,            7200},

2 hours as the maximum might be too short for some people. e.g. once
a day might be all that some people will want this to happen because
they have slowly growing log files - they stay in cache, will most
likely trigger the "keep prealloc" heuristic, but can often go 5
minutes without being modified.


Dave Chinner

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