xfs
[Top] [All Lists]

Re: [PATCH 5/8] xfs: implement iomap based buffered write path

To: Brian Foster <bfoster@xxxxxxxxxx>
Subject: Re: [PATCH 5/8] xfs: implement iomap based buffered write path
From: Christoph Hellwig <hch@xxxxxx>
Date: Tue, 3 May 2016 20:15:57 +0200
Cc: Christoph Hellwig <hch@xxxxxx>, rpeterso@xxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20160503150217.GA8014@xxxxxxxxxxxxxxx>
References: <1460494382-14547-1-git-send-email-hch@xxxxxx> <1460494382-14547-6-git-send-email-hch@xxxxxx> <20160414125814.GE20696@xxxxxxxxxxxxxxx> <20160502182523.GB7077@xxxxxx> <20160503150217.GA8014@xxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.17 (2007-11-01)
On Tue, May 03, 2016 at 11:02:19AM -0400, Brian Foster wrote:
> > Because the interface from the core iomap code need to pass the
> > length of the actually mapped range, and the amount of bytes successfully
> > written into it to the filesystem, as other filesystems will require
> > this for their locking.  We need to convert it back at some point,
> > and it seems more logical here than in the caller.
> > 
> 
> I'm not asking about the interface... or at least I'm not following your
> point. I'm just suggesting that the calculation of end_fsb is wrong.
> E.g., if the intent is to punch out the range that was allocated but not
> written to, shouldn't the range to punch be [offset + written, offset +
> length]?

Oh, yes.  It probably should - let me fix it and re-run xfstests..

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