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 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.)