| To: | Brian Foster <bfoster@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH] xfs: don't trigger fsync log force based on inode pin count |
| From: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
| Date: | Wed, 22 Apr 2015 15:06:11 -0700 |
| Cc: | Dave Chinner <david@xxxxxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <20150422220244.GA48944@xxxxxxxxxxxxxxx> |
| References: | <1429713466-22137-1-git-send-email-bfoster@xxxxxxxxxx> <20150422161509.GA27237@xxxxxxxxxxxxx> <20150422171322.GB6688@xxxxxxxxxxxxxxx> <20150422211845.GP21261@dastard> <20150422220244.GA48944@xxxxxxxxxxxxxxx> |
| User-agent: | Mutt/1.5.23 (2014-03-12) |
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. |
| <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, Brian Foster |
|---|---|
| Next by Date: | Re: [PATCH] xfs: don't trigger fsync log force based on inode pin count, Brian Foster |
| Previous by Thread: | Re: [PATCH] xfs: don't trigger fsync log force based on inode pin count, Brian Foster |
| Next by Thread: | Re: [PATCH] xfs: don't trigger fsync log force based on inode pin count, Brian Foster |
| Indexes: | [Date] [Thread] [Top] [All Lists] |