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
