| 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> |
|---|---|---|
| ||
| Previous by Date: | [PATCH 3/7] xfs: add configurable error support to metadata buffers, Carlos Maiolino |
|---|---|
| Next by Date: | Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io, Rudoff, Andy |
| Previous by Thread: | Re: [PATCH 5/8] xfs: implement iomap based buffered write path, Brian Foster |
| Next by Thread: | Re: [PATCH 00/19 v2] mkfs cleaning, Eric Sandeen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |