Re: [PATCH v4 8/8] xfs: add background scanning to clear EOFBLOCKS inodes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 27, 2012 at 01:45:52PM -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 based on the new eofb_timer tunable (default to 5m). The
> background scanner performs unfiltered, best effort scans (which
> skips inodes under lock contention or with a dirty cache mapping).
> 
> Signed-off-by: Brian Foster <bfoster@xxxxxxxxxx>
> ---
>  fs/xfs/xfs_globals.c |    1 +
>  fs/xfs/xfs_linux.h   |    1 +
>  fs/xfs/xfs_mount.h   |    2 ++
>  fs/xfs/xfs_sync.c    |   30 ++++++++++++++++++++++++++++++
>  fs/xfs/xfs_sysctl.c  |    9 +++++++++
>  fs/xfs/xfs_sysctl.h  |    1 +
>  6 files changed, 44 insertions(+), 0 deletions(-)
> 
> diff --git a/fs/xfs/xfs_globals.c b/fs/xfs/xfs_globals.c
> index 76e81cf..fda9a66 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*100,		300*100,	7200*100},
>  };
> diff --git a/fs/xfs/xfs_linux.h b/fs/xfs/xfs_linux.h
> index 828662f..bbad99b 100644
> --- a/fs/xfs/xfs_linux.h
> +++ b/fs/xfs/xfs_linux.h
> @@ -118,6 +118,7 @@
>  #define xfs_rotorstep		xfs_params.rotorstep.val
>  #define xfs_inherit_nodefrag	xfs_params.inherit_nodfrg.val
>  #define xfs_fstrm_centisecs	xfs_params.fstrm_timer.val
> +#define xfs_eofb_centisecs	xfs_params.eofb_timer.val

Let's not propagate that stupid "centiseconds" unit any further.
Nobody uses it, and it was only introduced because jiffie was 10ms
and there were 100 to a second so it was easy to convert in the
code. I don't think there is any reason for needing sub-second
granularity for this background function, so seconds shoul dbe just
fine for it. If you think we nee dfiner granularity, milliseconds is
the nex tunit to choose....

>  
>  #define current_cpu()		(raw_smp_processor_id())
>  #define current_pid()		(current->pid)
> diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h
> index deee09e..bf5ecfa 100644
> --- a/fs/xfs/xfs_mount.h
> +++ b/fs/xfs/xfs_mount.h
> @@ -199,6 +199,8 @@ typedef struct xfs_mount {
>  	struct xfs_mru_cache	*m_filestream;  /* per-mount filestream data */
>  	struct delayed_work	m_sync_work;	/* background sync work */
>  	struct delayed_work	m_reclaim_work;	/* background inode reclaim */
> +	struct delayed_work	m_eofblocks_work; /* background eof blocks
> +						     trimming */
>  	struct work_struct	m_flush_work;	/* background inode flush */
>  	__int64_t		m_update_flags;	/* sb flags we need to update
>  						   on the next remount,rw */
> diff --git a/fs/xfs/xfs_sync.c b/fs/xfs/xfs_sync.c
> index c9e1c16..31f678a 100644
> --- a/fs/xfs/xfs_sync.c
> +++ b/fs/xfs/xfs_sync.c
> @@ -532,6 +532,31 @@ xfs_flush_worker(
>  	xfs_sync_data(mp, SYNC_TRYLOCK | SYNC_WAIT);
>  }
>  
> +/*
> + * Background scanning to trim post-EOF preallocated space. This is queued
> + * based on the 'eofb_centisecs' tunable (5m by default).
> + */
> +STATIC void
> +xfs_queue_eofblocks(
> +	struct xfs_mount *mp)
> +{
> +	rcu_read_lock();
> +	if (radix_tree_tagged(&mp->m_perag_tree, XFS_ICI_EOFBLOCKS_TAG))
> +		queue_delayed_work(xfs_syncd_wq, &mp->m_eofblocks_work,
> +			msecs_to_jiffies(xfs_eofb_centisecs * 10));
> +	rcu_read_unlock();
> +}

This will all need reworking for the new xfs_icache.c and per-mount
workqueue structuring. Fundamentally there is nothing wrong with
what you've done, it's just been reworked...

> +	{
> +		.procname	= "eofb_centisecs",

Ugh. Call it something users might understand. Say
"background_prealloc_discard_period", or something similarly
informative...

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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


[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux