Re: [DISCUSS] xfs allocation bitmap method over linux raid

[Nathan Scott <nscott@aconex.com>]

On Mon, 2007-01-29 at 08:49 +1100, Nathan Scott wrote:
> prealloc shouldn't be zero for writes that will extend the file size;
> but now that I think about it, I'm not sure how it could ever get set
> for a buffered write (delalloc), since by the time we come to do the
> actual allocation and writes to disk, the inode size will be beyond
> the allocation offset.  Hmm, maybe the logic in there needs a rethink
> (any thoughts there, Dave/Lachlan?)

I had a closer look, and remember now how this works - I was looking
in the wrong place entirely.  For real (not delayed) allocations, the
stripe alignment is performed within the allocator, so deep down in
the xfs_bmapi -> xfs_bmap_alloc -> xfs_bmap_btalloc call path.

In particular, see the big comment mid-way through xfs_bmap_btalloc..

         * If we are not low on available data blocks, and the
         * underlying logical volume manager is a stripe, and
         * the file offset is zero then try to allocate data
         * blocks on stripe unit boundary.
         * NOTE: ap->aeof is only set if the allocation length
         * is >= the stripe unit and the allocation offset is
         * at the end of file.

(the "file offset is zero" part seems misleading to me, since it
is not only aligning in that case).

So, the real answer to your "why isn't it aligning" question lies
in there - if you can instrument that code and figure out why you
aren't seeing allocation alignment adjustnments inside there, you
should be 99% of the way to understanding your problem.

cheers.

-- 
Nathan