A Unix semantics issue if your filesystem can snapshot arbitrary directories
A commentator on my entry on where I think btrfs went wrong mentioned that HammerFS 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:
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
.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
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
.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.)