Fedora lists are hostile to upstream collaboration via cross-posting, so I can only forward this for your information. This causes problems with the i686 builders. Thanks, Florian
--- Begin Message ---
- To: linux-btrfs@xxxxxxxxxxxxxxx
- Subject: btrfs loses 32-bit application compatibility after a while
- From: Florian Weimer <fweimer@xxxxxxxxxx>
- Date: Thu, 13 Jul 2023 10:09:31 +0200
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
--- End Message ---
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
