From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 13/20] xfs: rmap btree requires more reserved free space
Date: Fri, 10 Jul 2015 10:37:44 +1000 [thread overview]
Message-ID: <20150710003744.GE7943@dastard> (raw)
In-Reply-To: <20150625164103.GC36162@bfoster.bfoster>
On Thu, Jun 25, 2015 at 12:41:04PM -0400, Brian Foster wrote:
> On Wed, Jun 03, 2015 at 04:04:50PM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> >
> > The rmap btree is allocated from the AGFL, which means we have to
> > ensure ENOSPC is reported to userspace before we run out of free
> > space in each AG. The last allocation in an AG can cause a full
> > height rmap btree split, and that means we have to reserve at least
> > this many blocks *in each AG* to be placed on the AGFL at ENOSPC.
> > Update the various space calculation functiosn to handle this.
> >
> > Also, because the macros are now executing conditional code and are called quite
> > frequently, convert them to functions that initialise varaibles in the struct
> > xfs_mount, use the new variables everywhere and document the calculations
> > better.
> >
> > Signed-off-by: Dave Chinner <dchinner@redhat.com>
.....
> > + * so we set the number of set-aside blocks to 4 + 4*agcount when not using rmap
> > + * btrees.
> > + *
> > + * When rmap btrees are active, we have to consider that using the last block in
> > + * the AG can cause a full height rmap btree split and we need enough blocks on
> > + * the AGFL to be able to handle this. That means we have, in addition to the
> > + * above consideration, another (2 * mp->m_ag_levels) - 1 blocks required to be
> > + * available to the free list.
> > + */
>
> BTW, I think I get the 2 block per level log requirement in that a split
> requires logging the two blocks involved. Where does the 2nd block per
> level come in as an allocation requirement?
Yup, you are right, I've mixed the two conditions up. Split only
requires an extra block per level, plus a new root block. e.g. see
xfs_alloc_min_freelist()...
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:[~2015-07-10 0:38 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-03 6:04 [RFC PATCH 00/20] xfs: reverse mapping btree support Dave Chinner
2015-06-03 6:04 ` [PATCH 01/20] xfs: xfs_alloc_fix_freelist() can use incore perag structures Dave Chinner
2015-06-15 14:57 ` Brian Foster
2015-06-03 6:04 ` [PATCH 02/20] xfs: factor out free space extent length check Dave Chinner
2015-06-15 14:58 ` Brian Foster
2015-06-03 6:04 ` [PATCH 03/20] xfs: sanitise error handling in xfs_alloc_fix_freelist Dave Chinner
2015-06-15 14:58 ` Brian Foster
2015-06-15 21:51 ` Dave Chinner
2015-06-16 11:27 ` Brian Foster
2015-06-22 0:10 ` Dave Chinner
2015-06-03 6:04 ` [PATCH 04/20] xfs: clean up XFS_MIN_FREELIST macros Dave Chinner
2015-06-15 14:58 ` Brian Foster
2015-06-03 6:04 ` [PATCH 05/20] xfs: introduce rmap btree definitions Dave Chinner
2015-06-03 6:30 ` Darrick J. Wong
2015-06-03 6:34 ` Darrick J. Wong
2015-06-03 6:04 ` [PATCH 06/20] xfs: add rmap btree stats infrastructure Dave Chinner
2015-06-03 6:04 ` [PATCH 07/20] xfs: rmap btree add more reserved blocks Dave Chinner
2015-06-03 6:04 ` [PATCH 08/20] xfs: add owner field to extent allocation and freeing Dave Chinner
2015-06-24 19:09 ` Brian Foster
2015-06-24 21:13 ` Dave Chinner
2015-06-25 13:03 ` Brian Foster
2015-06-03 6:04 ` [PATCH 09/20] xfs: introduce rmap extent operation stubs Dave Chinner
2015-06-03 6:04 ` [PATCH 10/20] xfs: define the on-disk rmap btree format Dave Chinner
2015-06-03 6:04 ` [PATCH 11/20] xfs: add rmap btree growfs support Dave Chinner
2015-06-03 6:04 ` [PATCH 12/20] xfs: rmap btree transaction reservations Dave Chinner
2015-06-03 6:04 ` [PATCH 13/20] xfs: rmap btree requires more reserved free space Dave Chinner
2015-06-25 16:41 ` Brian Foster
2015-07-10 0:37 ` Dave Chinner [this message]
2015-06-03 6:04 ` [PATCH 14/20] xfs: add rmap btree operations Dave Chinner
2015-06-03 6:04 ` [PATCH 15/20] xfs: add an extent to the rmap btree Dave Chinner
2015-06-25 16:41 ` Brian Foster
2015-07-10 0:39 ` Dave Chinner
2015-06-03 6:04 ` [PATCH 16/20] xfs: remove an extent from " Dave Chinner
2015-06-03 6:04 ` [PATCH 17/20] xfs: add rmap btree geometry feature flag Dave Chinner
2015-06-03 6:04 ` [PATCH 18/20] xfs: add rmap btree block detection to log recovery Dave Chinner
2015-06-03 6:04 ` [PATCH 19/20] xfs: disable XFS_IOC_SWAPEXT when rmap btree is enabled Dave Chinner
2015-06-03 6:04 ` [PATCH 20/20] xfs: enable the rmap btree functionality Dave Chinner
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=20150710003744.GE7943@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.