On Thu, Sep 02, 2021 at 02:14:17PM +1000, NeilBrown wrote:
> On Thu, 02 Sep 2021, J. Bruce Fields wrote:
> > I looked back through a couple threads to try to understand why we
> > couldn't do that (on new filesystems, with a mkfs option to choose new
> > or old behavior) and still don't understand. But the threads are long.
> >
> > There are objections to a new mount option (which seem obviously wrong;
> > this should be a persistent feature of the on-disk filesystem).
>
> I hadn't thought much (if at all) about a persistent filesystem feature
> flag. I'll try that now.
>
> There are two features of interest. One is completely unique inode
> numbers, the other is reporting different st_dev for different
> subvolumes. I think these need to be kept separate, though the second
> would depend on the first. They would be similar to my "inumbits" and
> "numdevs" mount options, though with less flexibility. I think that
> they would need strong semantics to be acceptable - "mostly unique"
> isn't really acceptable once we are changing the on-disk data.
I don't quite follow that.
Also the "on-disk data" here is literally just one more flag bit in some
superblock field, right?
> I believe that some code *knows* that the root of any btrfs subvolumes
> has inode number 256. systemd seems to use this. I have no idea what
> else might depend on inode numbers in some way.
Looking. Ugh, yes, there's abtrfs_might_be_subvol that takes a struct
stat and returns:
return S_ISDIR(st->st_mode) && st->st_ino == 256;
I wonder why it does that? Are there situations where all it has is a
file descriptor (so it can't easily compare st_dev with the parent?)
And if you NFS-export and wanted to answer the same question on the
client side, I wonder what you'd do.
--b.
