Thanks a lot! After one-night sleep, my brain is clear to figure out inode bits and inode64 mount option with your explanation. And your suggestions are helpful too. : ) Su On Fri, May 11, 2018 at 5:20 AM Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: > On 5/10/18 12:31 PM, Su Yue wrote: > > Hi, XFS developers > > > > Recently, I was told that some 32bit applications don't work > > on large XFS filesystems. And it is caused by ino overflow in syscalls. > > > > If I don't misunderstand libxfs/xfs_format, XFS' absolute inode number > > consists of agno_log > > -agblklog-inopblog bits. > > So significative bits = ROUND(log2(Disk size / AG size)) + ROUND(log2(AG > > size / BLK size)) + ROUND(log2(BLK size / inode size)). Right? > > Does it mean that it's feasible to avoid ino overflow by control of disk > > size, AG size, block size, inode size when mkfs even the disk will be mount > > with option inode64. > Yes, inode number is an encoded disk location, and the encoding depends > on various other bits of filesystem geometry. > Note that "inode64" only means that it will /allow/ some inodes to exceed > 32 bits, it does not mean that every inode number /will/ be > 32 bits. > But most people don't want to constrain their filesystem geometry around > inode number sizing; if you require 32-bit inodes, just use the inode32 mount > option. > Or better yet, fix the application. :) > -Eric > > Thanks, > > Su -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
