Re: [PATCH v5 22/22] XIP: Add support for unwritten extents
From: Matthew Wilcox <hidden>
Date: 2014-01-28 03:49:00
Also in:
linux-fsdevel, linux-mm, lkml
Possibly related (same subject, not in this thread)
- 2014-01-23 · Re: [PATCH v5 22/22] XIP: Add support for unwritten extents · Ross Zwisler <hidden>
- 2014-01-23 · Re: [PATCH v5 22/22] XIP: Add support for unwritten extents · Matthew Wilcox <hidden>
- 2014-01-22 · Re: [PATCH v5 22/22] XIP: Add support for unwritten extents · Ross Zwisler <hidden>
- 2014-01-16 · [PATCH v5 22/22] XIP: Add support for unwritten extents · Matthew Wilcox <hidden>
On Mon, Jan 27, 2014 at 04:32:07PM -0700, Ross Zwisler wrote:
It looks like we have an additional bit of complexity with the hole case. The issue is that for holes, bh->b_size is just the full size of the write as set earlier in the function: bh->b_size = ALIGN(end - offset, PAGE_SIZE);quoted
From this code it seems like you hoped the call into get_block() would adjustbh->b_size to the size of the hole, allowing you to zero just the hole space in the user buffer. It doesn't look like it does, though, at least for ext4.
Argh. I got confused. ext4 *has* this information, it just doesn't propagate it into the bh if it's a hole! Should it? The comments in the direct IO code imply that it *may*, but doesn't *have* to. What it's doing now (not touching it) is probably wrong.
To just assume the current FS block is a hole, we can do something like this:
Yes, this should fix things on an interim basis. Bit inefficient, but it'll work.
quoted hunk ↗ jump to hunk
diff --git a/fs/xip.c b/fs/xip.c index 35e401e..e902593 100644 --- a/fs/xip.c +++ b/fs/xip.c@@ -122,7 +122,7 @@ static ssize_t xip_io(int rw, struct inode *inode, const struct if (hole) { addr = NULL; - size = bh->b_size - first; + size = (1 << inode->i_blkbits) - first; } else { retval = xip_get_addr(inode, bh, &addr); if (retval < 0) --To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>