xfs
[Top] [All Lists]

Re: [patch] Fix xfs_iunpin() sets I_DIRTY_SYNC after clear_inode().

To: David Chinner <dgc@xxxxxxx>, Takenori Nagano <t-nagano@xxxxxxxxxxxxx>
Subject: Re: [patch] Fix xfs_iunpin() sets I_DIRTY_SYNC after clear_inode().
From: Timothy Shimmin <tes@xxxxxxx>
Date: Fri, 13 Oct 2006 18:06:31 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20061013014651.GC19345@melbourne.sgi.com>
References: <45237CCE.4010007@ah.jp.nec.com> <20061006032617.GC11034@melbourne.sgi.com> <20061011064357.GN19345@melbourne.sgi.com> <452E32FF.8010109@ah.jp.nec.com> <20061013014651.GC19345@melbourne.sgi.com>
Sender: xfs-bounce@xxxxxxxxxxx


--On 13 October 2006 11:46:51 AM +1000 David Chinner <dgc@xxxxxxx> wrote:

Now, I am trying to ease the degradation.
Do you have any idea for resolving the degradation?

Did you see a degradation with your original fix? I suspect not.

I think that the lsn based flush is tripping over a sync
transaction "optimisation" - if the previous log buffer needs
syncing or is currently being synced, then we don't try to flush the
active log buffer straight away - we wait for the previous log
buffer to complete it's I/O in the hope that we get more
transactions into the current log buffer.

You're referring to the code in xlog_state_sync() for the XLOG_STATE_ACTIVE case with the big header comment. It looks to be the one place where we sleep (sv_wait) even when we haven't got XFS_LOG_SYNC set (which we don't have here AFAICT). In this case, waiting for the previous iclog to the given lsn's iclog.

--Tim


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