From: Brian Foster <bfoster@redhat.com>
To: xfs@oss.sgi.com
Cc: linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
dm-devel@redhat.com
Subject: [RFC v2 PATCH 00/10] dm-thin/xfs: prototype a block reservation allocation model
Date: Tue, 12 Apr 2016 12:42:43 -0400 [thread overview]
Message-ID: <1460479373-63317-1-git-send-email-bfoster@redhat.com> (raw)
Hi all,
This is v2 of the XFS and block device reservation experiment. The
significant changes in v2 are that the bdev interface has been condensed
to a single callback function, the XFS transaction reservation
management has been reworked to make transactions responsible for
tracking and releasing excess reservation (for non-delalloc cases) and a
workaround for the fallocate over-reservation issue is included. Beyond
that, this version adds a bunch of miscellaneous cleanups and fixes some
of the nastier locking/leak issues present in the first rfc.
Patches 1-2 refactor some XFS reserve pool and block accounting code in
preparation for subsequent patches. Patches 3-5 add block/device-mapper
reservation support. Patches 6-10 add the core reservation
infrastructure and management bits to XFS. See the link to the original
rfc below for instructions and further details around the purpose of
this series.
Finally, note that this is still highly experimental/theoretical and
should not be used on production systems. Thoughts, reviews, flames
appreciated.
Brian
rfcv2:
- Rebased to 4.6.0-rc3.
- Fix compile warnings reported by kbuild.
- Fix reservation leakage on fs ENOSPC.
- Fix mod_fdblocks locking to avoid BUG() (still racy).
- Fix XFS reserve block ENOSPC handling.
- Kill block wrappers, condense get/set/provision to a single callback.
- Update XFS transaction to track reservation, don't release excess on
provision.
- Add transaction noblkres mode, use for fallocate reservation
optimization.
rfc: http://oss.sgi.com/pipermail/xfs/2016-March/047673.html
Brian Foster (7):
xfs: refactor xfs_reserve_blocks() to handle ENOSPC correctly
xfs: replace xfs_mod_fdblocks() bool param with flags
xfs: thin block device reservation mechanism
xfs: adopt a reserved allocation model on dm-thin devices
xfs: handle bdev reservation ENOSPC correctly from XFS reserved pool
xfs: support no block reservation transaction mode
xfs: use contiguous bdev reservation for file preallocation
Joe Thornber (1):
dm thin: add methods to set and get reserved space
Mike Snitzer (2):
block: add block_device_operations methods to set and get reserved
space
dm: add methods to set and get reserved space
drivers/md/dm-thin.c | 181 +++++++++++++++++++++++++++--
drivers/md/dm.c | 41 +++++++
fs/xfs/Makefile | 1 +
fs/xfs/libxfs/xfs_alloc.c | 25 ++++
fs/xfs/libxfs/xfs_bmap.c | 17 ++-
fs/xfs/libxfs/xfs_shared.h | 2 +
fs/xfs/xfs_bmap_util.c | 29 ++++-
fs/xfs/xfs_fsops.c | 128 ++++++++++++++-------
fs/xfs/xfs_mount.c | 106 +++++++++++++++--
fs/xfs/xfs_mount.h | 12 +-
fs/xfs/xfs_thin.c | 260 ++++++++++++++++++++++++++++++++++++++++++
fs/xfs/xfs_thin.h | 31 +++++
fs/xfs/xfs_trace.h | 27 +++++
fs/xfs/xfs_trans.c | 94 +++++++++++++--
fs/xfs/xfs_trans.h | 1 +
include/linux/blkdev.h | 6 +
include/linux/device-mapper.h | 5 +
17 files changed, 880 insertions(+), 86 deletions(-)
create mode 100644 fs/xfs/xfs_thin.c
create mode 100644 fs/xfs/xfs_thin.h
--
2.4.11
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next reply other threads:[~2016-04-12 16:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-12 16:42 Brian Foster [this message]
2016-04-12 16:42 ` [RFC v2 PATCH 01/10] xfs: refactor xfs_reserve_blocks() to handle ENOSPC correctly Brian Foster
2016-04-12 16:42 ` [RFC v2 PATCH 02/10] xfs: replace xfs_mod_fdblocks() bool param with flags Brian Foster
2016-04-12 16:42 ` [RFC v2 PATCH 03/10] block: add block_device_operations methods to set and get reserved space Brian Foster
2016-04-14 0:32 ` Dave Chinner
2016-04-12 16:42 ` [RFC v2 PATCH 04/10] dm: add " Brian Foster
2016-04-12 16:42 ` [RFC v2 PATCH 05/10] dm thin: " Brian Foster
2016-04-13 17:44 ` Darrick J. Wong
2016-04-13 18:33 ` Brian Foster
2016-04-13 20:41 ` Brian Foster
2016-04-13 21:01 ` Darrick J. Wong
2016-04-14 15:10 ` Mike Snitzer
2016-04-14 16:23 ` Brian Foster
2016-04-14 20:18 ` Mike Snitzer
2016-04-15 11:48 ` Brian Foster
2016-04-12 16:42 ` [RFC v2 PATCH 06/10] xfs: thin block device reservation mechanism Brian Foster
2016-04-12 16:42 ` [RFC v2 PATCH 07/10] xfs: adopt a reserved allocation model on dm-thin devices Brian Foster
2016-04-12 16:42 ` [RFC v2 PATCH 08/10] xfs: handle bdev reservation ENOSPC correctly from XFS reserved pool Brian Foster
2016-04-12 16:42 ` [RFC v2 PATCH 09/10] xfs: support no block reservation transaction mode Brian Foster
2016-04-12 16:42 ` [RFC v2 PATCH 10/10] xfs: use contiguous bdev reservation for file preallocation Brian Foster
2016-04-12 20:04 ` [RFC PATCH] block: wire blkdev_fallocate() to block_device_operations' reserve_space Mike Snitzer
2016-04-12 20:39 ` Darrick J. Wong
2016-04-12 20:46 ` Mike Snitzer
2016-04-12 22:25 ` Darrick J. Wong
2016-04-12 21:04 ` Mike Snitzer
2016-04-13 0:12 ` Darrick J. Wong
2016-04-14 15:18 ` Mike Snitzer
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=1460479373-63317-1-git-send-email-bfoster@redhat.com \
--to=bfoster@redhat.com \
--cc=dm-devel@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--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).