Per-subvol compat flags?

[Mark Harmstone <mark@harmstone.com>]

Hi all,

I'm the creator of the Windows Btrfs driver. During the course of development,
it's become apparent that for 100% compatibility with NTFS there'd need to be
some minor changes to the disk format. Examples: Windows' LZNT1 compression
scheme, Windows' encryption scheme, case-sensitivity, arbitrary-length xattrs.

I'm loathe to nab a compat flag bit for these, as they're all relatively minor,
and most wouldn't be that useful for Linux. And sod's law says that if I
unilaterally grab the next bit, the Linux driver will sooner or later use the
same bit for something else.

Has anyone ever brought up the idea of per-subvol compat flags? The idea is that
if a new feature affects the FS root and nothing else, rather than adding a new
compat flag bit, there'd be an entry in the root tree after the ROOT_ITEM, e.g.

    (0x100, 0x85, 0x2ed1c081232d)   for a compat entry, or
    (0x100, 0x86, 0x85f7583bc4b0)   for a readonly compat entry

With the third number being an arbitrary identifier for the feature (i.e. like
a UUID). If the driver doesn't understand a certain feature, it'd make the
subvol readonly or inaccessible, as appropriate. It'd also have to disable
certain features, such as balancing, but the rest of the FS would be usable.

As I see it, there's several advantages to this approach:

* Because the feature identifier is a 64-bit integer rather than a bit, it
  increases the effective compat flag namespace from 64 bits to 2^64.

* It makes out-of-tree development a lot easier, as the increased namespace
  makes it feasible to distribute patches without worrying about what's
  going to happen upstream.

* It lowers the cost of implementing new features (i.e., you don't have to
  let users know that new filesystems will only work on Linux 5.x). This would
  be especially important for encryption, as security means that you'd have to
  make it easy to add new algorithms when necessary.

* It allows for features to be controlled by Linux CONFIG flags, meaning that
  e.g. embedded devices wouldn't be burdened with a new feature for all time.

Does anybody have any thoughts?

Mark