On Tue, Jan 22, 2019 at 01:13:28PM -0500, Brian Foster wrote: > > So, the nimaps == 0 case hits even for the data fork when running > > xfs/442 on a 1k block size file system. That test has generally been > > a fun source of bugs in the always_cow series. > > Hmm, Ok.. any idea how/why that is? I'm curious if this is an artifact > of this code being racy (i.e., nimaps == 0 occurs somehow on a range > external to the page) or there is some legitimate means to lose a > delalloc block under the locked page. If the latter, we should at least > document it in the code.. I haven't managed to pinpint it mostly because xfs_bmapi_write is such an unreadable mess. Based on that I decided to implement the idea of a separate xfs_bmapi_delalloc_convert helper again, mostly to try to understand what actuall is going on. This seems to work pretty reasonable after initial testing, except that it seems to unhide an issue in xfs/109 which doesn't look directly related. The current status is here: http://git.infradead.org/users/hch/xfs.git/shortlog/refs/heads/xfs-mapping-validation.2
