On Wed, Apr 23, 2014 at 03:47:19PM +1000, Dave Chinner wrote:
> On Tue, Apr 22, 2014 at 07:35:34PM -0400, Keyur Govande wrote:
> > I noticed that XFS chooses the AG based on the parent directory's AG
> > and only the next sequential one if there's no space available.
>
> Yes, that's what the inode64 allocator does. It tries to keep files
> in the same directory close together.
> > @@ -517,7 +517,7 @@ xfs_ialloc_ag_select(
> > * to mean that blocks must be allocated for them,
> > * if none are currently free.
> > */
> > - agno = pagno;
> > + agno = ((xfs_agnumber_t) prandom_u32()) % agcount;
> > flags = XFS_ALLOC_FLAG_TRYLOCK;
> > for (;;) {
> > pag = xfs_perag_get(mp, agno);
>
> Ugh. That might fix the interleaving, but it randomly distributes
> related files over the entire filesystem. Hence if you have random
> access to the files (like a database does) you now have random seeks
> across the entire filesystem rather than within AGs. You basically
> destroy any concept of data locality that the filesystem has.
BTW, the inode32 allocator (it's a mount option) does this. it's no
longer the default because a) it's always had terrible behaviour for
general workloads compared to inode64 and b) we don't care enough
about 32 bit applications failing to use stat64() anymore to stay
with inode32 by default...
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
