From: Andreas Gruenbacher <agruenba@redhat.com>
To: cluster-devel@redhat.com
Cc: Andreas Gruenbacher <agruenba@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
linux-fsdevel@vger.kernel.org
Subject: [PATCH 0/4] gfs2 iomap: fiemap and lseek
Date: Wed, 7 Jun 2017 16:11:43 +0200 [thread overview]
Message-ID: <1496844707-23398-1-git-send-email-agruenba@redhat.com> (raw)
Here's an update of a patch queue that implements iomap in gfs2, switches
fiemap over to use iomap, and now also implements lseek SEEK_HOLE and SEEK_DATA
on top of iomap as well. Several issues with the previous version of this
patch queue have been fixed:
* Adds a IOMAP_F_BOUNDARY iomap flag that indicates when iomap has reached
a "metadata boundary", and fetching the next mapping is likely to incur an
additional I/O. This flag is used to set the bh buffer boundary flag.
* lseek SEEK_HOLE / SEEK_DATA is now implemented using a vfs helper and some
filesystem wiring-up code. This could be made generic if the iomap_ops are
exposed at the vfs level.
* Rounding fixes now that gfs2_get_iomap takes byte numbers instead of block
numbers.
* Fixes to make gfs2_get_iomap work beyond EOF (needed for allocations).
* Glock lock taking has been moved from gfs2_get_iomap to its callers; it
made no sense to drop glocks when iterating mappings.
* The gfs2_iomap tracepoint is now split into gfs2_iomap_start and
gfs2_iomap_end.
This patch queue still doesn't handle multi-page writes via iomap, but having
reasonable fiemap and lseek implementations is a start at least.
Thanks,
Andreas
Andreas Gruenbacher (1):
gfs2: Implement lseek SEEK_HOLE / SEEK_DATA via iomap
Bob Peterson (3):
GFS2: Make height info part of metapath
GFS2: Implement iomap for block_map
GFS2: Switch fiemap implementation to use iomap
fs/gfs2/Kconfig | 1 +
fs/gfs2/bmap.c | 292 ++++++++++++++++++++++++++++++++++++--------------
fs/gfs2/bmap.h | 4 +
fs/gfs2/file.c | 14 ++-
fs/gfs2/inode.c | 54 ++++++++--
fs/gfs2/inode.h | 1 +
fs/gfs2/trace_gfs2.h | 65 +++++++++++
fs/iomap.c | 55 ++++++++++
include/linux/iomap.h | 5 +-
9 files changed, 398 insertions(+), 93 deletions(-)
--
2.7.4
next reply other threads:[~2017-06-07 14:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-07 14:11 Andreas Gruenbacher [this message]
2017-06-07 14:11 ` [PATCH 1/4] GFS2: Make height info part of metapath Andreas Gruenbacher
2017-06-07 14:11 ` [PATCH 2/4] GFS2: Implement iomap for block_map Andreas Gruenbacher
2017-06-07 14:11 ` [PATCH 3/4] GFS2: Switch fiemap implementation to use iomap Andreas Gruenbacher
2017-06-07 14:11 ` [PATCH 4/4] gfs2: Implement lseek SEEK_HOLE / SEEK_DATA via iomap Andreas Gruenbacher
2017-06-07 14:15 ` 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=1496844707-23398-1-git-send-email-agruenba@redhat.com \
--to=agruenba@redhat.com \
--cc=cluster-devel@redhat.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
/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).