On Fri, Mar 16, 2018 at 04:05:22PM +0200, Amir Goldstein wrote: > Hi guys, > > I am trying to get a lower bound for unused inode number MSB on > a mounted xfs super block, so I can publish it on struct super_block. Sorry, what? The inode number is owned by the filesystem - nobody should be touching it or making assumptions they can screw with it in any way. > This doesn't need to be a tight lower bound, but it needs to be > a loewr bound that cannot change with growfs nor when > remounting with different options (i.e. inode64). > > This is needed for overlayfs to be able to use the unused upper bits > for overlayfs inode number namespace (see [1]). SO you're assuming that filesystems don't ever encode information into their inode numbers. I've already got plans to use a bunch of the unused upper bits in the inode number internally in XFS for subvolumes, and ISTR that Darrick was mulling a use for some of them a while back, too... > I realize that for a given agcount, a "soft" lower bound of unused > upper bits is agno_log-agblklog-inopblog, which makes the "hard" > lower bound 32-agblklog-inopblog, so I think I can use this number. > > I was staring at this definition and tried to figure out where this > absolute limit of 56 used bits came from: > #define XFS_MAXINUMBER ((xfs_ino_t)((1ULL << 56) - 1ULL)) > > Is this number really correct? If yes, then where does the constrain > on maximum 56 bits come from? Yes, 56 bits is the current maximum *physical* inode number - the inode number is currently a physical representation of the location on disk. 56 bits is needed to represent inodes in 2^63 bytes of physical space. Off the top of my head, it works out something like this for a a 512 byte inode, 4k block size filesystem: bits range meaning 6 0-63 inode # in chunk 7-22 1TB block offset in AG of inode 0 blkspag / bsize / inopblk 2^30 / 2^12 / 2^3 = 2^15 23-55 AGNO AG number The breakdown of bits change for different inode and block sizes, but the worse case comes out somewhere around 56 bits... *but* #define NULLFSINO ((xfs_ino_t)-1) is a valid inode number on disk, indicating that the field is not holding an inode number. the MSB indicates the inode number is a "virtual" inode number, holding some special significance that is not directly a physical inode number. Hence we actually use all 64 bits of the inode number on disk, and hence there are no free bits in the inode number for anyone outside XFS to use. IOWs, I think your plan is DOA because we already use the entire 64 bit space in the inode number field and have plans for the "unused bits" already in motion.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
