From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 71AA97F37 for ; Wed, 22 Apr 2015 12:13:53 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 606C9304048 for ; Wed, 22 Apr 2015 10:13:49 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id ygGdtErBbgGK5QrV (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 22 Apr 2015 10:13:49 -0700 (PDT) Date: Wed, 22 Apr 2015 13:13:23 -0400 From: Brian Foster Subject: Re: [PATCH] xfs: don't trigger fsync log force based on inode pin count Message-ID: <20150422171322.GB6688@bfoster.bfoster> References: <1429713466-22137-1-git-send-email-bfoster@redhat.com> <20150422161509.GA27237@infradead.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20150422161509.GA27237@infradead.org> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Christoph Hellwig Cc: xfs@oss.sgi.com On Wed, Apr 22, 2015 at 09:15:09AM -0700, Christoph Hellwig wrote: > On Wed, Apr 22, 2015 at 10:37:46AM -0400, Brian Foster wrote: > > There are probably a couple different ways to handle this. We could log > > the inode in the bmap cases in order to preserve the pincount check. > > I'd favor that. For one performance should be better, second we really > need to dirty the inode anyway for v5 file systems as that's the > mechanism used to increment di_changecount. > Yeah, that's a good point. I noticed that in xfs_trans_log_inode() when debugging but didn't think much about it since I reproduced on v4. I can get performance back with the aforementioned cil push fix, but if the path forward is behavior where the inode is going to be logged anyways, that is decent reason to emulate such behavior in the pre-v5 case. Note that we have the following in xfs_bmapi_write(): if (bma.logflags) xfs_trans_log_inode(tp, ip, bma.logflags); ... and some other places. I don't reproduce this particular problem on v5, so something else might be logging the inode here. That strikes me as not what we want with regard to the change count, however.. Brian > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs