On Thu, Mar 10, 2016 at 06:22:07AM -0800, Christoph Hellwig wrote: > Sorry for the second reply to the same mail - I expect this defintion to > be in patch 7, where it logically belongs.. > > > +#define XFS_RMAP_BLOCK(mp) \ > > (xfs_sb_version_hasfinobt(&((mp)->m_sb)) ? \ > > XFS_FIBT_BLOCK(mp) + 1 : \ > > XFS_IBT_BLOCK(mp) + 1) > > Is there any good reason for the variable offset for the rmap block. > Yes, it saves one otherwise unused block per AG, but fixed offsets > for metadata make a format much easier to understand. The root btree blocks are not a fixed location. The moment the tree splits to the root we get a new root block and the old root is now at a lower level of the tree. IOWs, it doesn't matter if there is a hole at the time of growfs/mkfs laying out the initial tree roots because they are going to move around anyway. Also, it depends on the sector vs block size as to where these are initially located, too. A disk with 512 byte sectors and 4k block size results in the root btree blocks being located from fsb 2-7. On a 4k sector/4k block size fs has the root btree blocks located from fsb 4-9. Hence I really don't think it matters if the initial location changes depenedent on features and geometry as you have to look it up with xfs_db anyway to find it even on a pristine new filesystem... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
