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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
