Re: [PATCH 22/27] xfs: use generic get_unaligned_beXX helpers

[Christoph Hellwig <hch@infradead.org>]

On Wed, Jul 06, 2011 at 01:44:21PM +1000, Dave Chinner wrote:
> Hmmmm. I wonder if it is a hold-over from the days of 4GB AGs?

Probably.

> That would have meant inode numbers used 6 bits for the chunk index,
> 2^22 - 2^6 for the agbno and 2^32 for the agno, which gives 54 bits
> maximum inode number and so XFS_MAXINUMBER @ 56 bits makes sense, as
> does the zero high byte in the dir2 inode number.
> 
> Now we have 2^30 bits for the agbno+chunk index, and 32 bits for the
> agno, so inode numbers can reach 62 bits, which is outside the range
> of the 56-bit MAXINUMBER limit.
> 
> So my questions are now this:
> 	- did we lose that checking when we converted the rest of
> 	  the directory code to use the generic byte swapping
> 	  functions?

The history lesson tells us:

Before my commit

	"Fix and streamline directory inode number handling"

we didn't do any capping for them in Linux since the early days
of adding byte swaping support.  However my commit was modelled
after the original IRIX code, which had the same behaviour as my
code in the same XFS_DI_LO/HI helpers.

Even back then XFS_GET_DIR_INO8/XFS_SET_DIR_INO8 were only
used by the dir2_sf code, but the dirv1 used a similar XFS_GET_DIR_INO
macro for all read accesses, which had the same limitation.  Writes
on the other hand were done using XFS_DIR_SF_PUT_DIRINO (even for
non-shortform directories), which did not discard the most significant
bytes.

> 	- do we need to increase XFS_MAXINUMBER to reflect the
> 	  current reality of 1TB AGs and simply ignore the zero high
> 	  byte restriction?

I think so.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs