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 08/10] xfs: handle bdev reservation ENOSPC correctly from XFS reserved pool
Date: Tue, 12 Apr 2016 12:42:51 -0400 [thread overview]
Message-ID: <1460479373-63317-9-git-send-email-bfoster@redhat.com> (raw)
In-Reply-To: <1460479373-63317-1-git-send-email-bfoster@redhat.com>
The XFS reserved block pool holds blocks from general allocation for
internal purposes. When enabled, these blocks shall also carry a
reservation from the block device to guarantee they are usable.
The reserved pool allocation code currently uses a retry algorithm based
on the available space estimation. It assumes that an inability to
allocate blocks based on the estimation is a transient problem. Now that
block allocation attempts bdev reservation, however, an ENOSPC could
originate from the block device and might not be transient.
Because the retry algorithm cannot distinguish between fs block
allocation and bdev reservation, separate the two operations in this
particular case. If the bdev reservation fails, back off the reservation
delta until something can be reserved or return ENOSPC to the caller.
Once a bdev reservation is made, attempt to allocate blocks from the fs
and return to the original retry algorithm based on the free space
estimation. This prevents infinite retries in the event of a reserved
pool allocation request that cannot be satisfied from a bdev that
supports reservation.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
fs/xfs/xfs_fsops.c | 29 +++++++++++++++++++++++++++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c
index 87d4b1b..79ae408 100644
--- a/fs/xfs/xfs_fsops.c
+++ b/fs/xfs/xfs_fsops.c
@@ -40,6 +40,7 @@
#include "xfs_trace.h"
#include "xfs_log.h"
#include "xfs_filestream.h"
+#include "xfs_thin.h"
/*
* File system operations
@@ -676,6 +677,7 @@ xfs_reserve_blocks(
__uint64_t request;
__int64_t free;
int error = 0;
+ sector_t res = 0;
/* If inval is null, report current values and return */
if (inval == (__uint64_t *)NULL) {
@@ -743,6 +745,28 @@ xfs_reserve_blocks(
fdblks_delta = delta;
/*
+ * Reserve pool blocks must carry a block device reservation (if
+ * enabled). The block device could be much closer to ENOSPC
+ * than the fs (i.e., a thin or snap device), so try to reserve
+ * the bdev space first.
+ */
+ spin_unlock(&mp->m_sb_lock);
+ if (mp->m_thin_reserve) {
+ while (fdblks_delta) {
+ res = xfs_fsb_res(mp, fdblks_delta, false);
+ error = xfs_thin_reserve(mp, res);
+ if (error != -ENOSPC)
+ break;
+
+ fdblks_delta >>= 1;
+ }
+ if (!fdblks_delta || error) {
+ spin_lock(&mp->m_sb_lock);
+ break;
+ }
+ }
+
+ /*
* We'll either succeed in getting space from the free block
* count or we'll get an ENOSPC. If we get a ENOSPC, it means
* things changed while we were calculating fdblks_delta and so
@@ -752,8 +776,9 @@ xfs_reserve_blocks(
* Don't set the reserved flag here - we don't want to reserve
* the extra reserve blocks from the reserve.....
*/
- spin_unlock(&mp->m_sb_lock);
- error = xfs_mod_fdblocks(mp, -fdblks_delta, 0);
+ error = __xfs_mod_fdblocks(mp, -fdblks_delta, 0);
+ if (error && mp->m_thin_reserve)
+ xfs_thin_unreserve(mp, res);
spin_lock(&mp->m_sb_lock);
}
--
2.4.11
next prev parent 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 [RFC v2 PATCH 00/10] dm-thin/xfs: prototype a block reservation allocation model Brian Foster
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 ` Brian Foster [this message]
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-9-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).