From: Dave Chinner <david@fromorbit.com>
To: Alain Renaud <arenaud@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH V2] xfs: prevent xfs_bmap_extsize_align() to exceed maximum extent size.
Date: Thu, 19 Jul 2012 13:30:27 +1000 [thread overview]
Message-ID: <20120719033027.GD23387@dastard> (raw)
In-Reply-To: <50059437.6070705@sgi.com>
On Tue, Jul 17, 2012 at 06:35:03PM +0200, Alain Renaud wrote:
> Here is a second revision. Needed to remove an ASSERT and added a new one.
FWIW, the change log goes in the section after the first --- (i.e.
where the diffstat is) as it is not needed in the commit message...
> xfs: prevent xfs_bmap_extsize_align() to exceed maximum extent size.
>
> When trying to do preallocation that exceed the the maximum size of
> an extent, the extsize alignment can exceed this value.
>
> We are already trying to solve this issue for delay allocation but we
> have the same with prealloc. So I think the simple solution is to limit
> the size in xfs_bmap_extsize_align() and remove the code specific to
> delay allocation.
>
> We do have a simple test case to confirm that the problem exist.
>
> # cd/xfs_dir/
> # xfs_io -c 'extsize 4m' .
> # xfs_io -f -c 'resvsp 0 8g' test_file
> XFS_IOC_RESVSP64: No space left on device
simpler: xfs_io -f -c 'extsize 4m' -c 'resvsp 0 8g' test_file
I was able to reproduce this, for a short while. Then it went away:
$ /usr/sbin/xfs_io -f -c 'extsize 4m' -c 'resvsp 0 8g' test_file
XFS_IOC_RESVSP64: No space left on device
$ /usr/sbin/xfs_io -f -c 'extsize 4m' -c 'resvsp 0 8g' test_file
XFS_IOC_RESVSP64: No space left on device
$ /usr/sbin/xfs_io -f -c 'extsize 4m' -c 'resvsp 0 8g' -c bmap test_file
XFS_IOC_RESVSP64: No space left on device
test_file: no extents
$ /usr/sbin/xfs_io -f -c 'extsize 4m' -c 'resvsp 0 8g' -c "bmap -vp" test_file
test_file:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
0: [0..16732159]: 238228480..254960639 8 (11596800..28328959) 16732160 10011
1: [16732160..16781311]: 445662208..445711359 15 (20727808..20776959) 49152 10011
$
$ rm test_file
$ /usr/sbin/xfs_io -f -c 'extsize 4m' -c 'resvsp 0 8g' -c "bmap -vp" test_file
test_file:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
0: [0..16732159]: 238228480..254960639 8 (11596800..28328959) 16732160 10011
1: [16732160..16781311]: 445662208..445711359 15 (20727808..20776959) 49152 10011
$ rm test_file
$ /usr/sbin/xfs_io -f -c 'extsize 4m' -c 'resvsp 0 8g' -c "bmap -vp" test_file
test_file:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
0: [0..16732655]: 238227984..254960639 8 (11596304..28328959) 16732656 11011
1: [16732656..16781807]: 445662208..445711359 15 (20727808..20776959) 49152 10011
$ rm test_file
$ /usr/sbin/xfs_io -f -c 'extsize 4m' -c 'resvsp 0 8g' -c "bmap -vp" test_file
test_file:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
0: [0..16732655]: 238227984..254960639 8 (11596304..28328959) 16732656 11011
1: [16732656..16781807]: 445662208..445711359 15 (20727808..20776959) 49152 10011
$ uname -a
Linux disappointment 3.4-trunk-amd64 #1 SMP Tue Jun 26 17:23:03 UTC 2012 x86_64 GNU/Linux
And it appears to be realted to the fact I don't have an AG with an
8G free extent in it. Initially, the trace was indicating the
allocation was asking for a signle 8GB extent, and failing because
it didn't find one, hence ENOSPC. I'd see this:
kworker/4:0-22 [004] 1223944.610192: xfs_alloc_vextent_loopfailed: dev 9:0 agno 2 agbno 1213074 minlen 2097152 maxlen 2097152 mod 0 prod 1024 minleft 1 total 0 alignment 128 minalignslop 0 len 2661202812 type NEAR_BNO otype START_BNO wasdel 0 wasfromfl 136 isfl 0 userdata 2 firstblock 0xffffffffffffffff
where the minlen/maxlen values indicate the acceptible extent range.
When it started succeeding, I'd see this:
kworker/5:1-49 [005] 1225590.604825: xfs_alloc_vextent_loopfailed: dev 9:0 agno 15 agbno 471304 minlen 1348384 maxlen 2097152 mod 0 prod 1024 minleft 1 total 0 alignment 1 minalignslop 0 len 2348686204 type NEAR_BNO otype START_BNO wasdel 0 wasfromfl 136 isfl 0 userdata 2 firstblock 0xffffffffffffffff
Note the minlen? It's been shortened to reflect the fact I don't
have 8GB freespace extents in the filesystem.
Firstly, can you reproduce this on your test setup, Alain? What is
the size (and number) of the AGs in the filesystem? If you do see
this behaviour, then the alignment code is not the problem...
> + * Make sure we do not exceed the maximum len of an extent.
> + */
> + align_alen = XFS_FILBLKS_MIN(align_alen,
> + MAXEXTLEN - (MAXEXTLEN % extsz));
I don't think that is correct. alignment happens at both the start
and end of the extent, so you need to take into account two lots of
(extsz - 1) blocks of range extension for alignment.
> + /*
> * If the previous block overlaps with this proposed allocation
> * then move the start forward without adjusting the length.
> */
> @@ -1999,7 +2004,6 @@ xfs_bmap_extsize_align(
> return XFS_ERROR(EINVAL);
> } else {
> ASSERT(orig_off >= align_off);
> - ASSERT(orig_end <= align_off + align_alen);
Why is this removed? What it is checking is that the aligned end
covers the entire range of the original space requested.
> }
> #ifdef DEBUG
> @@ -2009,6 +2013,7 @@ xfs_bmap_extsize_align(
> ASSERT(align_off >= prevp->br_startoff + prevp->br_blockcount);
> #endif
> + ASSERT(align_alen <= MAXEXTLEN);
> *lenp = align_alen;
> *offp = align_off;
> return 0;
> @@ -4450,13 +4455,6 @@ xfs_bmapi_reserve_delalloc(
> /* Figure out the extent size, adjust alen */
> extsz = xfs_get_extsz_hint(ip);
> if (extsz) {
> - /*
> - * Make sure we don't exceed a single extent length when we
> - * align the extent by reducing length we are going to
> - * allocate by the maximum amount extent size aligment may
> - * require.
> - */
> - alen = XFS_FILBLKS_MIN(len, MAXEXTLEN - (2 * extsz - 1));
This code is allowing for both head and tail extent alignment....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-07-19 3:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120712154554.377970666@sgi.com>
2012-07-13 10:09 ` [PATCH] xfs: prevent xfs_bmap_extsize_align() to exceed maximum extent size Alain Renaud
2012-07-17 16:35 ` [PATCH V2] " Alain Renaud
2012-07-19 3:30 ` Dave Chinner [this message]
2012-07-19 8:20 ` Alain Renaud
2012-07-20 1:44 ` Dave Chinner
2012-07-20 8:05 ` Alain Renaud
2012-08-23 16:52 ` [PATCH V3] xfs: prevent xfs_bmapi_write() " Alain Renaud
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=20120719033027.GD23387@dastard \
--to=david@fromorbit.com \
--cc=arenaud@sgi.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