Subject: Re: Problems with "fss" (file system snapshot) device
To: None <email@example.com>
From: Thor Lancelot Simon <firstname.lastname@example.org>
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