Re: What to do about subvolumes?

["J. Bruce Fields" <bfields@fieldses.org>]

On Wed, Dec 01, 2010 at 05:52:07PM -0800, Michael Vrable wrote:
> On Wed, Dec 01, 2010 at 03:09:52PM -0500, Josef Bacik wrote:
> >On Wed, Dec 01, 2010 at 03:00:08PM -0500, J. Bruce Fields wrote:
> >>I think you're already fine:
> >>
> >>	# mkdir TMP
> >>	# dd if=/dev/zero of=TMP-image bs=1M count=512
> >>	# mkfs.btrfs TMP-image
> >>	# mount -oloop TMP-image TMP/
> >>	# btrfs subvolume create sub-a
> >>	# btrfs subvolume create sub-b
> >>	../readdir-inos .
> >>	. 256 256
> >>	.. 256 4130609
> >>	sub-a 256 256
> >>	sub-b 257 256
> >>
> >>Where readdir-inos is my silly test program below, and the first
> >>number is from readdir, the second from stat.
> >>
> >
> >Heh as soon as I typed my email I went and actually looked at the
> >code, looks like for readdir we fill in the root id, which will be
> >unique, so hotdamn we are good and I don't have to use a stupid
> >incompat flag.  Thanks for checking that :),
> 
> Except, aren't the inode numbers within a filesystem and the
> sunbvolume tree IDs allocated out of separate namespaces?  I don't
> think there's anything preventing a file/directory from having an
> inode number that clashes with one of the snapshots.
> 
> In fact, this already happens in the example above: "." (inode 256
> in the root subvolume) and "sub-a" (subvolume ID 256).

Oof, yes, I overlooked that.

> (Though I still don't understand the semantics well enough to say
> whether we need all the inode numbers returned by readdir to be
> distinct.)

On normal mounts they're the number of the inode that was mounted over,
so normally they'd be unique across the parent filesystem.....  I don't
know if anything depends on that.

--b.