On Thu, Dec 11, 2003 at 12:30:53AM -0800, Jason Thorpe wrote:
> 
> 3. Snapshots do not persist across reboots.  This is because there is 
> no way of knowing if a file system was modified while the "fss" 
> instance was not attached to it.  Again, this is a problem for 
> long-lived snapshots.  There are plenty of scenarios where long-lived 
> snapshots might be desirable (e.g. long-running back-up, policy-based 
> tiered storage management, etc.).

This is a complete strawman.  Mounting a snapshotted filesystem
read-write without using the snapshot device is an obvious case of
"don't *do* that, then!".

A block-snapshotting device is generally useful, and we need _some_
form of snapshotting for FFS.  I'm sorry it's not exactly what you'd
prefer, but honestly, it in no way prevents you nor anyone else from
implementing exactly what you'd prefer.  Having a block-snapshotting
device available does not prevent you from integrating the McKusick
snapshotting code into FFS; it does not prevent you from writing a
snapshotting cleaner for LFS; all it does is provide functionality
that, evidently, you won't use.  Optional functionality, that will
be useful to me and to many others immediately (as in "right now")
but that you don't even have to include in your kernel.

This can be used to snapshot FFS, LFS, ext2fs, msdosfs, ntfs, and
even HFS if/when we get HFS support.  We don't "own" some of those
filesystem formats, so we can't really integrate support for
snapshotting into them.  There are some drawbacks to this approach,
but it is highly flexible and useful and I believe that it is
valuable to NetBSD.

Thor