That's only supported on FSes that declare they are re-entrant enough to support it - just FFS for now For FAT et al, the snapshot needs to be on another filesystem (which can be another of the same type, as long as it's a different mount).

Volume manager: My bad. But fss is even more of a nasty design than a volume manager. I hate to think what it's doing to allow the snapshot to live on the FS it's snapshotting.

Consistency: I was thinking that it'd be nice if the kernel atomically did a sync before taking the snapshot, in order to flush all pending data and metadata to the filesystem so it's in a consistent state, then it occurred to me that perhaps it does; I'd have to read the source to check. In which case, the warning about mounting a non-cleanly-unmounted filesystem when mounting a snapshot can safely be ignored. Even for a busy FS, this would mean that a snapshot just meant a short interruption in throughput.

Duplication: What volume manager? The fss snapshot driver just stores the snapshot in a file. Thus reusing the filesystem's block allocator. And what 2Gb file are you referring to?

Performance: Again, what volume manager? fss will hurt performance of the original disk during operation since it's doing a copy-on-write snapshot, so every write to the original disk becomes a read-write-write cycle, but not reads as they can just go straight to the original disk; while the snapshot virtual-disk is read-only, its reads will be a bit slower since they amount to looking the block up in an index structure in the snapshot file or falling back to the original disk. However, performance of the snapshot virtual-disk isn't really critical; the only real cost is the copy-on-write on the original disk. But this isn't hiding any details of the discs from the FS, it's just interposing an extra copy on write, and one that goes away as soon as you've removed the snapshot.

Duplicate databases: Both the FS and volume manager do block allocation. So two bits of duplicate code to go wrong, plus the volume manager doesn't know it can reuse the blocks when you delete that 2Gb file.

Performance: The volume manager hides details of the discs from the FS which can be used to increase performance. See how fast Sun's ZFS + write optimised flash + read optimised flash + slow SATA discs combination goes in it's new Amber Road products for an example of why you'd want such a blatant layering violation.

For a start, it's much more complex to implement at that level. More bloated code to harbour bugs. Block-level snapshotting is much easier to validate, which is nice for something trusted with our MP3 stashes.

And snapshots at the FS level make your snapshot system orthogonal to your file system, so they can be chosen and developed independently. Under NetBSD's system, I can happily snapshot a FAT32 filesystem.

What the fss driver does is the same thing NetApp does when used as an iSCSI target rather than an NFS server, or what virtualisation systems do when snapshotting a virtual disk - it's a tried and tested technique. It's just nice to have it available at the OS level...

Shouldn't it be supported at the FS level? Like ZFS and the NetApp stuff.