btrfs loses 32-bit application compatibility after a while

[Florian Weimer <fweimer@redhat.com>]

As far as I can tell, btrfs assigns inode numbers sequentially using
this function:

int btrfs_get_free_objectid(struct btrfs_root *root, u64 *objectid)
{
	int ret;
	mutex_lock(&root->objectid_mutex);

	if (unlikely(root->free_objectid >= BTRFS_LAST_FREE_OBJECTID)) {
		btrfs_warn(root->fs_info,
			   "the objectid of root %llu reaches its highest value",
			   root->root_key.objectid);
		ret = -ENOSPC;
		goto out;
	}

	*objectid = root->free_objectid++;
	ret = 0;
out:
	mutex_unlock(&root->objectid_mutex);
	return ret;
}

Even after deletion of the object, inode numbers are never reused.

This is a problem because after creating and deleting two billion files,
the 31-bit inode number space is exhausted.  (Not sure if negative inode
numbers are a thing, so there could be one extra bit.)  From that point
onwards, future files will end up with an inode number that cannot be
represented with the non-LFS interfaces (stat, getdents, etc.), causing
system calls to fail with EOVERFLOW.

For ABI reasons, we can't switch everything to 64-bit ino_t and LFS
interfaces.  (If we could recompile, we wouldn't still be using 32-bit
software.)

So far, we have seen this on our 32-bit Koji builders, which create and
delete many, many files.  But I suspect end users will encounter it
eventually, too.

It seems to me that the on-disk format already allows range searches on
inode numbers (see btrfs_init_root_free_objectid), so maybe this could
be used to find a sufficiently large unused range to allocate from.

Thanks,
Florian