From: Andreas Gruenbacher <agruenba@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH 0/4] gfs2 iomap: fiemap and lseek
Date: Thu, 25 May 2017 21:39:31 +0200 [thread overview]
Message-ID: <1495741175-31326-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-05-25 19:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-25 19:39 Andreas Gruenbacher [this message]
2017-05-25 19:39 ` [Cluster-devel] [PATCH 1/4] GFS2: Make height info part of metapath Andreas Gruenbacher
2017-05-25 19:39 ` [Cluster-devel] [PATCH 2/4] GFS2: Implement iomap for block_map Andreas Gruenbacher
2017-05-25 19:39 ` [Cluster-devel] [PATCH 3/4] GFS2: Switch fiemap implementation to use iomap Andreas Gruenbacher
2017-05-25 19:39 ` [Cluster-devel] [PATCH 4/4] gfs2: Implement lseek SEEK_HOLE / SEEK_DATA via iomap Andreas Gruenbacher
2017-06-06 13:41 ` Bob Peterson
2017-06-07 13:23 ` Christoph Hellwig
2017-06-07 14:11 ` Andreas Gruenbacher
-- strict thread matches above, loose matches on Subject: below --
2017-06-07 14:11 [Cluster-devel] [PATCH 0/4] gfs2 iomap: fiemap and lseek Andreas Gruenbacher
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=1495741175-31326-1-git-send-email-agruenba@redhat.com \
--to=agruenba@redhat.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).