> No, because it would also have to compact space on closure, among other
> things.

No, it would not.   You would define the following operations:

typedef struct inode_tag {
  u_int32_t magic;
  size_t len;
  char *data;
} tag_t;

fcntl (file, F_ADD_TAG, tag_t)
      returns 0 for success, -1 for failure
      possible ERRNO values:
	       ENOSPC - no space to store this tag.

fcntl (file, F_GET_TAG, tag_t)
      looks up field with magic number from tag_t.
      on success:
      - returns 0
      - stores up to tag_t.len bytes through tag_t.data pointer
        sets tag_t.len to total bytes for tag, which may be greater than
	incoming tag_t.len.
      on failure:
      - returns -1
      - errno = ENOENT
      - tag_t unmodified

fcntl (file, F_DELETE_TAG, tag_t)
      on success:
      - returns 0
      - specified tag has been deleted.
      on failure:
      - returns -1
      - errno = ENOENT

Compression of the buffer happens in the delete call, not on file
closure.  It's no pro-o-blem!

> The reason for keeping the magic number in host order is so that the
> overlay fs can tell if it needs to byteswap the payload.

So make the magic number 23 bits, and use one bit to indicate byte
order.

> No, I disagree. Sticking a database in the inode sounds like a mess to me.
> And that is what you're proposing.

Putting in an opaque data field with flag bits sounds like a mess to
me.   Maybe this isn't a good argument.

> And just what, exactly, are other people going to want to stick in here?

Other file attributes?   You're proposing a userland API - I can think
of things I'd like to stick in there.   Small things, obviously.   GUI
hints, for example.

> I really don't forsee having two overlay fs's running on top of each
> other at the same time, each needing per-inode storage.

If it's something that more than one filesystem can use, and somebody
implements a filesystem other than yours that uses it, then at some
point the two will be stacked, and it won't work.   If somebody finds
a non-filesystem use for it, that won't work with your filesystem.

> We can leave hooks in the design so it could be supported, but it
> really strikes me as rare.

How about a filesystem with macos-like resource forks, where the
inode of the resource fork is stored in the opaque data?   How about
ACLs?   There are tons of possible uses for this.

			       _MelloN_