From: Bob Peterson <rpeterso@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: xfs@oss.sgi.com, vishal l verma <vishal.l.verma@intel.com>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 09/15] fs: iomap based fiemap implementation
Date: Mon, 23 May 2016 16:09:26 -0400 (EDT) [thread overview]
Message-ID: <1651455378.10041082.1464034166002.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <1462783638-4968-10-git-send-email-hch@lst.de>
----- Original Message -----
| Add a simple fiemap implementation based on iomap_ops, partially based
| on a previous implementation from Bob Peterson <rpeterso@redhat.com>.
|
| Signed-off-by: Christoph Hellwig <hch@lst.de>
| ---
| fs/iomap.c | 90
| +++++++++++++++++++++++++++++++++++++++++++++++++++
| include/linux/iomap.h | 3 ++
| 2 files changed, 93 insertions(+)
|
| diff --git a/fs/iomap.c b/fs/iomap.c
| index f84c6eb..7e639bf 100644
| --- a/fs/iomap.c
| +++ b/fs/iomap.c
| @@ -405,3 +405,93 @@ out_unlock:
| return ret;
| }
| EXPORT_SYMBOL_GPL(iomap_page_mkwrite);
| +
| +struct fiemap_ctx {
| + struct fiemap_extent_info *fi;
| + struct iomap prev;
| +};
| +
| +static int iomap_to_fiemap(struct fiemap_extent_info *fi,
| + struct iomap *iomap, u32 flags)
| +{
| + switch (iomap->type) {
| + case IOMAP_HOLE:
| + /* skip holes */
| + return 0;
| + case IOMAP_DELALLOC:
| + flags |= FIEMAP_EXTENT_DELALLOC | FIEMAP_EXTENT_UNKNOWN;
| + break;
| + case IOMAP_UNWRITTEN:
| + flags |= FIEMAP_EXTENT_UNWRITTEN;
| + break;
| + case IOMAP_MAPPED:
| + break;
| + }
| +
| + return fiemap_fill_next_extent(fi, iomap->offset,
| + iomap->blkno != IOMAP_NULL_BLOCK ? iomap->blkno << 9: 0,
| + iomap->length, flags | FIEMAP_EXTENT_MERGED);
| +
| +}
| +
| +static loff_t
| +iomap_fiemap_actor(struct inode *inode, loff_t pos, loff_t length, void
| *data,
| + struct iomap *iomap)
| +{
| + struct fiemap_ctx *ctx = data;
| + loff_t ret = length;
| +
| + if (iomap->type == IOMAP_HOLE)
| + return length;
| +
| + ret = iomap_to_fiemap(ctx->fi, &ctx->prev, 0);
| + ctx->prev = *iomap;
| + switch (ret) {
| + case 0: /* success */
| + return length;
| + case 1: /* extent array full */
| + return 0;
| + default:
| + return ret;
| + }
| +}
| +
| +int iomap_fiemap(struct inode *inode, struct fiemap_extent_info *fi,
| + loff_t start, loff_t len, struct iomap_ops *ops)
| +{
| + struct fiemap_ctx ctx;
| + loff_t ret;
| +
| + memset(&ctx, 0, sizeof(ctx));
| + ctx.fi = fi;
| + ctx.prev.type = IOMAP_HOLE;
| +
| + ret = fiemap_check_flags(fi, FIEMAP_FLAG_SYNC);
| + if (ret)
| + return ret;
| +
| + ret = filemap_write_and_wait(inode->i_mapping);
| + if (ret)
| + return ret;
| +
| + while (len > 0) {
| + ret = iomap_apply(inode, start, len, 0, ops, &ctx,
| + iomap_fiemap_actor);
| + if (ret < 0)
| + return ret;
| + if (ret == 0)
| + break;
| +
| + start += ret;
| + len -= ret;
| + }
| +
| + if (ctx.prev.type != IOMAP_HOLE) {
| + ret = iomap_to_fiemap(fi, &ctx.prev, FIEMAP_EXTENT_LAST);
| + if (ret < 0)
| + return ret;
| + }
| +
| + return 0;
| +}
| +EXPORT_SYMBOL_GPL(iomap_fiemap);
| diff --git a/include/linux/iomap.h b/include/linux/iomap.h
| index 854766f..b3deee1 100644
| --- a/include/linux/iomap.h
| +++ b/include/linux/iomap.h
| @@ -3,6 +3,7 @@
|
| #include <linux/types.h>
|
| +struct fiemap_extent_info;
| struct inode;
| struct iov_iter;
| struct kiocb;
| @@ -63,5 +64,7 @@ int iomap_truncate_page(struct inode *inode, loff_t pos,
| bool *did_zero,
| struct iomap_ops *ops);
| int iomap_page_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf,
| struct iomap_ops *ops);
| +int iomap_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
| + loff_t start, loff_t len, struct iomap_ops *ops);
|
| #endif /* LINUX_IOMAP_H */
| --
| 2.1.4
|
|
Hi Christoph,
I've been looking at this again. Where are the calls to the fs-specific bits
for fiemap? It looks like iomap_fiemap calls iomap_apply, which calls
iomap_fiemap_actor, but that doesn't call any ops->iomap_get_iomap or similar.
It calls the iomap_begin (which BTW has a comment that says "Execute a iomap
write" which is probably wrong and should be more generic, as for cases like
fiemap) and it calls iomap_end. But it never calls an fs-specific actor
anywhere. Am I missing something? My earlier version passed in the actor
function, as per Dave Chinner's request, but yours doesn't.
Regards,
Bob Peterson
Red Hat File Systems
next prev parent reply other threads:[~2016-05-23 20:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-09 8:47 iomap infrastructure and multipage writes V4 Christoph Hellwig
2016-05-09 8:47 ` [PATCH 01/15] dax: export a low-level __dax_zero_page_range helper Christoph Hellwig
2016-05-11 22:43 ` Verma, Vishal L
2016-05-09 8:47 ` [PATCH 02/15] fs: move struct iomap from exportfs.h to a separate header Christoph Hellwig
2016-05-09 8:47 ` [PATCH 03/15] fs: introduce iomap infrastructure Christoph Hellwig
2016-05-09 8:47 ` [PATCH 04/15] fs: support DAX based iomap zeroing Christoph Hellwig
2016-05-09 8:47 ` [PATCH 05/15] xfs: make xfs_bmbt_to_iomap available outside of xfs_pnfs.c Christoph Hellwig
2016-05-09 8:47 ` [PATCH 06/15] xfs: reorder zeroing and flushing sequence in truncate Christoph Hellwig
2016-05-09 8:47 ` [PATCH 07/15] xfs: implement iomap based buffered write path Christoph Hellwig
2016-05-09 8:47 ` [PATCH 08/15] xfs: remove buffered write support from __xfs_get_blocks Christoph Hellwig
2016-05-09 8:47 ` [PATCH 09/15] fs: iomap based fiemap implementation Christoph Hellwig
2016-05-23 20:09 ` Bob Peterson [this message]
2016-05-24 13:10 ` Christoph Hellwig
2016-05-26 18:19 ` Bob Peterson
2016-05-26 22:57 ` Dave Chinner
2016-05-09 8:47 ` [PATCH 10/15] xfs: use iomap " Christoph Hellwig
2016-05-09 8:47 ` [PATCH 11/15] xfs: use iomap infrastructure for DAX zeroing Christoph Hellwig
2016-05-09 8:47 ` [PATCH 12/15] xfs: handle 64-bit length in xfs_iozero Christoph Hellwig
2016-05-09 8:47 ` [PATCH 13/15] xfs: use xfs_zero_range in xfs_zero_eof Christoph Hellwig
2016-05-09 8:47 ` [PATCH 14/15] xfs: split xfs_free_file_space in manageable pieces Christoph Hellwig
2016-05-09 8:47 ` [PATCH 15/15] xfs: kill xfs_zero_remaining_bytes Christoph Hellwig
2016-05-11 22:42 ` iomap infrastructure and multipage writes V4 Verma, Vishal L
2016-06-01 6:35 ` Dave Chinner
2016-06-01 12:31 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1651455378.10041082.1464034166002.JavaMail.zimbra@redhat.com \
--to=rpeterso@redhat.com \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=vishal.l.verma@intel.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).