== A Unix semantics issue if your filesystem can snapshot arbitrary directories

A commentator on [[my entry on where I think btrfs went wrong
../linux/BtrfsCoreMistake]] mentioned that [[HammerFS
http://en.wikipedia.org/wiki/HAMMER]] allows snapshots of arbitrary
directories instead of requiring you to plan ahead and create
subvolumes or sub-filesystems as btrfs and ZFS do. As it happens,
allowing this raises a little question about Unix semantics. Let's
illustrate it with some hypothetical commands:

.pn prewrap on
>  mkdir a b
>  touch a/fred
>  ln a/fred b/
>  snapshot --readonly a@test
>  ls -li a/fred .snap/a@test/fred
>  rm -f b/fred
>  ls -li a/fred .snap/a@test/fred

Here is the question: what are the inode numbers and link counts shown
for _.snap/a@test/fred_ in the two ls's?

Clearly the real _a/fred_ retains the same inode number and goes
from a link count of 2 to a link count of 1 after _b/fred_ is
removed. If the snapshotted version also changes link count what
we have is observable changes in filesystem state in a theoretically
read-only snapshot, and also it's not clear how to actually implement
this. If the link count doesn't change it's actually incorrect since
you can't find anywhere the theoretical second link for
_.snap/a@test/fred_. But at least it's easy to implement.

(As far as filesystem boundaries go, the only sane choice is to
have _.snap/a@test_ be a separate filesystem with a separate 'device'
and so on. That avoids massive problems around inode numbers.)

All of this is avoided if you force _a_ to be a separate filesystem
because then you can't create this link in the first place. You're
guaranteed that all hard links in the snapshot are to things that
are also in the snapshot and so won't change.

In practice most people probably don't care about accurate link
counts for files in a snapshot and this is likely just a nit. But
I can't help but come up with these odd corner cases when I think
about things like snapshotting arbitrary directories.

(I suspect this hard link issue is one reason that ZFS doesn't allow
you to turn an existing directory hierarchy into a sub-filesystem, a
restriction that sometimes annoys me.)