On Sun, Nov 30, 2014 at 07:08:51PM +0530, Shriramana Sharma wrote: > On Sun, Nov 30, 2014 at 5:29 PM, Hugo Mills <h...@carfax.org.uk> wrote: > > > > In the data structures on disk, it's 5. The kernel aliases 0 to > > mean subvolid 5. > > So why 5 and not just 0 which seems a logical choice? On top of this, > one needs to alias 0 to 5!
All of the trees used in the FS metadata have an ID number. The "well-known" trees have small, fixed IDs: #define BTRFS_ROOT_TREE_OBJECTID 1ULL #define BTRFS_EXTENT_TREE_OBJECTID 2ULL #define BTRFS_CHUNK_TREE_OBJECTID 3ULL #define BTRFS_DEV_TREE_OBJECTID 4ULL #define BTRFS_FS_TREE_OBJECTID 5ULL #define BTRFS_ROOT_TREE_DIR_OBJECTID 6ULL #define BTRFS_CSUM_TREE_OBJECTID 7ULL #define BTRFS_QUOTA_TREE_OBJECTID 8ULL #define BTRFS_UUID_TREE_OBJECTID 9ULL Note that "the" FS tree has ID 5. A subvolume is basically another FS tree. Subvolumes other than the top level are given dynamically- allocated IDs starting from 256. Note also that the root, chunk, device and extent trees are all more important, lower level information than any FS tree, so they logically have lower numbers (and were probably implemented earlier). There's no particular reason that it couldn't have been designed with the initial FS tree as ID 0, but it simply wasn't. However, changing this value now would result in two incompatible versions of btrfs -- neither one would be able to deal with the other's filesystems, because the FS tree has a different ID. (And writing code to cope with both would be painful, disruptive and error-prone.) The cost of fixing this minor nit would, I think, far outweigh any benefits you'd get from it. Hence the "alias" for 0, which is (IIRC) done up-front in the ioctl interface, and therefore has few places that it could go wrong or affect the main code of the FS. Hugo. -- Hugo Mills | "How deep will this sub go?" hugo@... carfax.org.uk | "Oh, she'll go all the way to the bottom if we don't http://carfax.org.uk/ | stop her." PGP: 65E74AC0 | U571
signature.asc
Description: Digital signature
