On Fri, Dec 08, 2023 at 12:34:28PM +0100, Donald Buczek wrote: > On 12/8/23 03:49, Kent Overstreet wrote: > > > We really only need 6 or 7 bits out of the inode number for sharding; > > then 20-32 bits (nobody's going to have a billion snapshots; a million > > is a more reasonable upper bound) for the subvolume ID leaves 30 to 40 > > bits for actually allocating inodes out of. > > > > That'll be enough for the vast, vast majority of users, but exceeding > > that limit is already something we're technically capable of: we're > > currently seeing filesystems well over 100 TB, petabyte range expected > > as fsck gets more optimized and online fsck comes. > > 30 bits would not be enough even today: > > buczek@done:~$ df -i /amd/done/C/C8024 > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/md0 2187890304 618857441 1569032863 29% /amd/done/C/C8024 > > So that's 32 bit on a random production system ( 618857441 == 0x24e303e1 ). > > And if the idea to produce unique inode numbers by hashing the filehandle > into 64 is followed, collisions definitely need to be addressed. With > 618857441 objects, the probability of a hash collision with 64 bit is already > over 1% [1].
Oof, thanks for the data point. Yeah, 64 bits is clearly not enough for a unique identifier; time to start looking at how to extend statx.
