| To: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH] xfs: don't trigger fsync log force based on inode pin count |
| From: | Brian Foster <bfoster@xxxxxxxxxx> |
| Date: | Wed, 22 Apr 2015 18:10:47 -0400 |
| Cc: | Dave Chinner <david@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <20150422220611.GA8881@xxxxxxxxxxxxx> |
| References: | <1429713466-22137-1-git-send-email-bfoster@xxxxxxxxxx> <20150422161509.GA27237@xxxxxxxxxxxxx> <20150422171322.GB6688@xxxxxxxxxxxxxxx> <20150422211845.GP21261@dastard> <20150422220244.GA48944@xxxxxxxxxxxxxxx> <20150422220611.GA8881@xxxxxxxxxxxxx> |
| User-agent: | Mutt/1.5.23 (2014-03-12) |
On Wed, Apr 22, 2015 at 03:06:11PM -0700, Christoph Hellwig wrote: > On Wed, Apr 22, 2015 at 06:02:44PM -0400, Brian Foster wrote: > > That was what I thought at first but I bumped the extent count a couple > > times and still couldn't reproduce. I was curious enough to track it > > down and it is actually the time update again. For whatever reason, I > > think the crc mechanism is throwing the timing off and just hiding the > > problem again. E.g., no-op xfs_vn_time_update() and the problem > > reproduces on v5 as well. > > Actually, its the changecount again. If MS_I_VERSION is set > the VFS will always call into ->xfs_vn_time_update. Ah, I see. Yeah, that explains the time update then... Brian |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH] xfs: don't trigger fsync log force based on inode pin count, Christoph Hellwig |
|---|---|
| Next by Date: | Re: [PATCH] xfs: call xfs_idestroy_fork() in xfs_ilock() critical section, Dave Chinner |
| Previous by Thread: | Re: [PATCH] xfs: don't trigger fsync log force based on inode pin count, Christoph Hellwig |
| Next by Thread: | [PATCH] xfs: call xfs_idestroy_fork() in xfs_ilock() critical section, Waiman Long |
| Indexes: | [Date] [Thread] [Top] [All Lists] |