Re: [PATCH v5 1/8] Btrfs: introduce a tree for items that map UUIDs to something

[Chris Mason <chris.mason@fusionio.com>]

Quoting Stefan Behrens (2013-06-21 04:47:20)
> On Thu, 20 Jun 2013 12:47:04 -0700, Zach Brown wrote:
> > 
> >> +/* for items that use the BTRFS_UUID_KEY */
> >> +#define BTRFS_UUID_ITEM_TYPE_SUBVOL 0 /* for UUIDs assigned to subvols */
> >> +#define BTRFS_UUID_ITEM_TYPE_RECEIVED_SUBVOL        1 /* for UUIDs assigned to
> >> +                                               * received subvols */
> >> +
> >> +/* a sequence of such items is stored under the BTRFS_UUID_KEY */
> >> +struct btrfs_uuid_item {
> >> +    __le16 type;    /* refer to BTRFS_UUID_ITEM_TYPE* defines above */
> >> +    __le32 len;     /* number of following 64bit values */
> >> +    __le64 subid[0];        /* sequence of subids */
> >> +} __attribute__ ((__packed__));
> >> +
> > 
> > [...]
> > 
> >>  /*
> >> + * Stores items that allow to quickly map UUIDs to something else.
> >> + * These items are part of the filesystem UUID tree.
> >> + * The key is built like this:
> >> + * (UUID_upper_64_bits, BTRFS_UUID_KEY, UUID_lower_64_bits).
> >> + */
> >> +#if BTRFS_UUID_SIZE != 16
> >> +#error "UUID items require BTRFS_UUID_SIZE == 16!"
> >> +#endif
> >> +#define BTRFS_UUID_KEY      251
> > 
> > Why do we need this btrfs_uuid_item structure?  Why not set the key type
> > to either _SUBVOL or _RECEIVED_SUBVOL instead of embedding structs with
> > those types under items with the constant BTRFS_UUID_KEY.  Then use the
> > item size to determine the number of u64 subids.  Then the item has a
> > simple array of u64s in the data which will be a lot easier to work
> > with.
> 
> Maintaining a 16 bit uuid_type field inside the item is done in order to
> avoid wasting type values for the key. The type field in the key has a
> width of 8 bits, so far 34 type values are defined in ctree.h.
> 
> As long as such items are in separated trees, their type value could be
> reused in the future when the 8 bit type field is exhausted.
> 
> There was some discussion in #btrfs about this topic on 2013-04-26.
> There are pros and cons. The uuid_type field in the item allows to use
> the uuid items generically outside of the uuid tree since it occupies
> only one type value in the 8 bit type field. On the other hand, if the 8
> bit type field in the key is exhausted, it saves lines of codes and
> avoids complexity to implement a common way to expand this field instead
> of implementing multiplexing layers at multiple places, although maybe
> with some added performance penalty.
> 
> Anybody else with an opinion for this topic?

I've been thinking about this, and while I clearly did not have this use
of uuids in mind originally, they have become a key part of the FS.  They
deserve their own bits in the type field.

I know this is not an easy thing to redo, but long term it really looks
worth it to me.

-chris