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@xxxxxxxxxx>
Seems sane on reading the implementation. I'll see if I still think
that way when I read the code that uses it ;)