xfs
[Top] [All Lists]

Re: [PATCH 06/13] xfs: xfs_sync_data is redundant.

To: Ben Myers <bpm@xxxxxxx>
Subject: Re: [PATCH 06/13] xfs: xfs_sync_data is redundant.
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 4 Oct 2012 11:07:27 +1000
Cc: Brian Foster <bfoster@xxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20121004000552.GO13214@xxxxxxx>
References: <1348807485-20165-1-git-send-email-david@xxxxxxxxxxxxx> <1348807485-20165-7-git-send-email-david@xxxxxxxxxxxxx> <5069F9B0.50804@xxxxxxxxxx> <20121002001021.GJ23520@dastard> <506A38D1.6090204@xxxxxxxxxx> <506AE5AD.60509@xxxxxxxxxx> <20121002205124.GS23520@dastard> <20121004000552.GO13214@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, Oct 03, 2012 at 07:05:52PM -0500, Ben Myers wrote:
> Hey Dave,
> 
> On Wed, Oct 03, 2012 at 06:51:24AM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@xxxxxxxxxx>
> > 
> > writeback_inodes_sb_if_idle() is not sufficient to trigger delalloc
> > conversion fast enough to prevent spurious ENOSPC whent here are
> > hundreds of writers, thousands of small files and GBs of free RAM.
> > Change this to use sync_sb_inodes() to block callers while we wait
> > for writeback like the previous xfs_flush_inodes implementation did.
> > 
> > We have to hold the s_umount lock here, but because this call can
> > nest inside i_mutex (the parent directory in the create case, held
> > by the VFS), we have to use down_read_trylock() to avoid potential
> > deadlocks. In practice, this trylock will succeed on almost every
> > attempt as unmount/remount type operations are exceedingly rare.
> > 
> > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
<snip>

> Is this the one you want to go with?  I'd prefer to apply this to patch 6
> itself rather than check in the regression followed by the fix.  If you'd like
> resubmit this patch that's great, otherwise I'll be happy to repost the 
> result.

Yes, this is the version that is necessary. Folding it back
into the original patch is fine as long as you fold the commit
message as well to explain why it was implemented this way.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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