[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@xxxxxxxxxxxxxxxxx>
References: <45237CCE.4010007@xxxxxxxxxxxxx> <20061006032617.GC11034@xxxxxxxxxxxxxxxxx> <20061011064357.GN19345@xxxxxxxxxxxxxxxxx> <452E32FF.8010109@xxxxxxxxxxxxx> <20061013014651.GC19345@xxxxxxxxxxxxxxxxx>
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

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.


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