xfs
[Top] [All Lists]

Re: [PATCH 3/5] [XFS] Block callers of xfs_flush_inodes() correctly.

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 3/5] [XFS] Block callers of xfs_flush_inodes() correctly.
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 16 Mar 2009 21:27:19 +1100
Cc: xfs@xxxxxxxxxxx, mpatocka@xxxxxxxxxx
In-reply-to: <20090316091331.GC2636@xxxxxxxxxxxxx>
Mail-followup-to: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, mpatocka@xxxxxxxxxx
References: <1237116707-25793-1-git-send-email-david@xxxxxxxxxxxxx> <1237116707-25793-4-git-send-email-david@xxxxxxxxxxxxx> <20090316091331.GC2636@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Mon, Mar 16, 2009 at 05:13:31AM -0400, Christoph Hellwig wrote:
> On Sun, Mar 15, 2009 at 10:31:45PM +1100, Dave Chinner wrote:
> > xfs_flush_inodes() currently uses a magic timeout to wait for
> > some inodes to be flushed before returning. This isn't
> > really reliable but used to be the best that could be done
> > due to deadlock potential of waiting for the entire flush.
> > 
> > Now the inode flush is safe to execute while we hold page
> > and inode locks, we can wait for all the inodes to flush
> > synchronously. Convert the wait mechanism to a completion
> > to do this efficiently. This should remove all remaining
> > spurious ENOSPC errors from the delayed allocation reservation
> > path.
> 
> Why do we queue it up to a different thread if we synchronously wait
> for it anyway?

To avoid competing with flushes that may already be in progress.
This way all the concurrent ENOSPC flushes are serialised by the
xfssyncd so it can do optimal flushing without being interfered
with....

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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