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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
