From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH v3 09/18] xfs: support min/max agbno args in block allocator
Date: Mon, 9 Feb 2015 11:01:12 +1100 [thread overview]
Message-ID: <20150209000112.GJ4251@dastard> (raw)
In-Reply-To: <1423252385-3063-10-git-send-email-bfoster@redhat.com>
On Fri, Feb 06, 2015 at 02:52:56PM -0500, Brian Foster wrote:
> The block allocator supports various arguments to tweak block allocation
> behavior and set allocation requirements. The sparse inode chunk feature
> introduces a new requirement not supported by the current arguments.
> Sparse inode allocations must convert or merge into an inode record that
> describes a fixed length chunk (64 inodes x inodesize). Full inode chunk
> allocations by definition always result in valid inode records. Sparse
> chunk allocations are smaller and the associated records can refer to
> blocks not owned by the inode chunk. This model can result in invalid
> inode records in certain cases.
>
> For example, if a sparse allocation occurs near the start of an AG, the
> aligned inode record for that chunk might refer to agbno 0. If an
> allocation occurs towards the end of the AG and the AG size is not
> aligned, the inode record could refer to blocks beyond the end of the
> AG. While neither of these scenarios directly result in corruption, they
> both insert invalid inode records and at minimum cause repair to
> complain, are unlikely to merge into full chunks over time and set land
> mines for other areas of code.
>
> To guarantee sparse inode chunk allocation creates valid inode records,
> support the ability to specify an agbno range limit for
> XFS_ALLOCTYPE_NEAR_BNO block allocations. The min/max agbno's are
> specified in the allocation arguments and limit the block allocation
> algorithms to that range. The starting 'agbno' hint is clamped to the
> range if the specified agbno is out of range. If no sufficient extent is
> available within the range, the allocation fails. For backwards
> compatibility, the min/max fields can be initialized to 0 to disable
> range limiting (e.g., equivalent to min=0,max=agsize).
>
> Signed-off-by: Brian Foster <bfoster@redhat.com>
Seems sane on reading the implementation. I'll see if I still think
that way when I read the code that uses it ;)
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-02-09 0:02 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-06 19:52 [PATCH v3 00/18] xfs: sparse inode chunks Brian Foster
2015-02-06 19:52 ` [PATCH v3 01/18] xfs: add sparse inode chunk alignment superblock field Brian Foster
2015-02-06 22:40 ` Dave Chinner
2015-02-08 16:04 ` Brian Foster
2015-02-08 21:43 ` Dave Chinner
2015-02-06 19:52 ` [PATCH v3 02/18] xfs: use sparse chunk alignment for min. inode allocation requirement Brian Foster
2015-02-06 19:52 ` [PATCH v3 03/18] xfs: sparse inode chunks feature helpers and mount requirements Brian Foster
2015-02-06 22:54 ` Dave Chinner
2015-02-06 19:52 ` [PATCH v3 04/18] xfs: introduce inode record hole mask for sparse inode chunks Brian Foster
2015-02-06 23:16 ` Dave Chinner
2015-02-08 16:06 ` Brian Foster
2015-02-08 21:57 ` Dave Chinner
2015-02-09 15:15 ` Brian Foster
2015-02-09 21:48 ` Dave Chinner
2015-02-10 12:58 ` Brian Foster
2015-02-06 19:52 ` [PATCH v3 05/18] xfs: create macros/helpers for dealing with " Brian Foster
2015-02-06 19:52 ` [PATCH v3 06/18] xfs: pass inode count through ordered icreate log item Brian Foster
2015-02-06 19:52 ` [PATCH v3 07/18] xfs: handle sparse inode chunks in icreate log recovery Brian Foster
2015-02-06 23:19 ` Dave Chinner
2015-02-08 16:06 ` Brian Foster
2015-02-06 19:52 ` [PATCH v3 08/18] xfs: helpers to convert holemask to/from generic bitmap Brian Foster
2015-02-08 23:54 ` Dave Chinner
2015-02-09 15:15 ` Brian Foster
2015-02-06 19:52 ` [PATCH v3 09/18] xfs: support min/max agbno args in block allocator Brian Foster
2015-02-09 0:01 ` Dave Chinner [this message]
2015-02-06 19:52 ` [PATCH v3 10/18] xfs: allocate sparse inode chunks on full chunk allocation failure Brian Foster
2015-02-09 1:25 ` Dave Chinner
2015-02-09 15:20 ` Brian Foster
2015-02-06 19:52 ` [PATCH v3 11/18] xfs: randomly do sparse inode allocations in DEBUG mode Brian Foster
2015-02-08 23:02 ` Dave Chinner
2015-02-09 15:20 ` Brian Foster
2015-02-06 19:52 ` [PATCH v3 12/18] xfs: filter out sparse regions from individual inode allocation Brian Foster
2015-02-08 22:49 ` Dave Chinner
2015-02-06 19:53 ` [PATCH v3 13/18] xfs: update free inode record logic to support sparse inode records Brian Foster
2015-02-08 22:33 ` Dave Chinner
2015-02-06 19:53 ` [PATCH v3 14/18] xfs: only free allocated regions of inode chunks Brian Foster
2015-02-06 19:53 ` [PATCH v3 15/18] xfs: skip unallocated regions of inode chunks in xfs_ifree_cluster() Brian Foster
2015-02-06 19:53 ` [PATCH v3 16/18] xfs: use actual inode count for sparse records in bulkstat/inumbers Brian Foster
2015-02-08 22:29 ` Dave Chinner
2015-02-06 19:53 ` [PATCH v3 17/18] xfs: add fs geometry bit for sparse inode chunks Brian Foster
2015-02-06 19:53 ` [PATCH v3 18/18] xfs: enable sparse inode chunks for v5 superblocks Brian Foster
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=20150209000112.GJ4251@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox