xfs
[Top] [All Lists]

Re: [PATCH 1/1] xfs: log the inode in ->write_inode calls for kupdate

To: Hans-Peter Jansen <hpj@xxxxxxxxx>
Subject: Re: [PATCH 1/1] xfs: log the inode in ->write_inode calls for kupdate
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Wed, 28 Dec 2011 16:39:46 -0500
Cc: xfs@xxxxxxxxxxx, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Paul Anderson <pha@xxxxxxxxx>, Sean Thomas Caron <scaron@xxxxxxxxx>
In-reply-to: <201112282235.57645.hpj@xxxxxxxxx>
References: <20111218154936.GA17626@xxxxxxxxxxxxx> <20111218154955.GB17626@xxxxxxxxxxxxx> <201112282235.57645.hpj@xxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, Dec 28, 2011 at 10:35:56PM +0100, Hans-Peter Jansen wrote:
> On Sunday 18 December 2011, 16:49:55 Christoph Hellwig wrote:
> > If the writeback code writes back an inode because it has expired we
> > currently use the non-blockin ->write_inode path.  This means any
> > inode that is pinned is skipped.  With delayed logging and a workload
> > that has very little log traffic otherwise it is very likely that an
> > inode that gets constantly written to is always pinned, and thus we
> > keep refusing to write it.  The VM writeback code at that point
> > redirties it and doesn't try to write it again for another 30
> > seconds.  This means under certain scenarious time based metadata
> > writeback never happens.
> 
> Wouldn't this qualify as STABLE material then?

Yes, it does.  But for something as complicated as XFS I'm not going to
do a simple Cc: to stable but will apply each patch individually and do
explicit testing of the backport.

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