Subject: Re: Problems with "fss" (file system snapshot) device
To: None <tech-kern@netbsd.org>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-kern
Date: 12/11/2003 11:51:55
On Thu, Dec 11, 2003 at 11:02:38AM -0500, Thor Lancelot Simon wrote:
> 
> 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!".

On the other hand, it would be good to be able to make this much
harder.  An illustritive question is "why doesn't this happen
for existing meta-disk devices like RAIDs"?  The answer is that
those devices have their own disklabel and their own partition
type -- so that the label on the outer device won't be of a type
that FFS will naively be willing to mount.

I think that fss needs to grow support for this.  It should
probably be careful to push the start of the actual "raw" partition
inside the fss up to a boundary from the start of the outer
partition that's likely to be acceptable to most RAIDs -- for
example, 1MB.  Smaller offsets such as some of our current
metadisk devices use run the risk of putting naively-aligned FS
structures or data writes smack in the middle of RAID stripes.

FWIW, I agree with Jason that:

* snapshots integrated into the filesystem are better -- necessary,
  really -- for *users*, rather than *administrators*, to use the
  snapshot facility.  Anyone who's worked at a NetApp site knows
  how much admin time is saved because .snapshot in each directory
  lets users recover their own lost data.

* the requirement that the fss backing store be dense is pretty
  unfortunate.  A backing store structured in extents would be
  a lot nicer.

I just happen to think that, right now, fss is useful and good,
albeit not for solving the problems Jason wants to solve with
snapshotting.

Thor