On Wed, Oct 22, 2003 at 12:44:53PM -0400, Stephan Uphoff wrote:
> 
> Jason Thorpe wrote:
> > 
> > On Wednesday, October 22, 2003, at 07:57  AM, Stephan Uphoff wrote:
> > 
> > > PS: Just for the record (feel free to ignore) as I don't think my
> > >     opinion is widely shared:
> > >     I don't like fs specific stuff in the block layer and would rather 
> > > see
> > >     a pseudo disk device for block interception being pushed on top of 
> > > the
> > >     disk device.
> > 
> > For snapshots, a shim device has at least two major problems:
> > 
> > 	- Requires a priori knowledge that you will want to take
> > 	  a snapshot at some point in the future (because you have
> > 	  to insert the shim).
> > 
> > 	- If you have an active snapshot, and then you reboot one day
> > 	  and the shim is not inserted for some reason, then your
> > 	  snapshot is now inconsistent and invalid.
> > 
> > ...and a third reason, which isn't a show-stopper, but something I 
> > consider important nonetheless:
> > 
> > 	- A single snapshot strategy may not be appropriate for all
> > 	  file system types.  For example, a snapshot device would
> > 	  be pretty much the perfectly WRONG approach for snapshotting
> > 	  LFS.  I think snapshot code belongs in the file system,
> > 	  because the file system can make better strategic decisions
> > 	  than some generic shim that COW's blocks can.
> > 
> >          -- Jason R. Thorpe <thorpej@wasabisystems.com>
> 
> 
> I agree that snapshot code belongs into the filesystem
> and that generic non fs specific snapshot block device are not desirable
> in this (specific) case.
> 
> However if a filessytem automatically pushes a (fs specific) interception 
> block layer on the stack at mount time (or later on the fly?) it gains
> at least the same functionality without requiring fs specific hooks in 
> spec_strategy.
> 
> 	Stephan

I can see two different approaches to file system snapshots:

1) Kirk McKusick ffs snapshots from FreeBSD. It is an extension of the
   ffs file system with these properties (I hope I get them right..):

   - Backing store is always the snapshotted file system.
   - The snapshot appears as a file whose size is the size of the file
     system. Blocks unallocated at the time of the snapshot read as 0's.
   - It allows up to 20 snapshots per file system
   - The snapshots survive unmounts and reboots.

   - Mounting or dumping the snapshot is possible through vnd(4) and/or
     some modifications to dump(8).
2) A somewhat generic approach similar to the fssnap from Solaris:

   - Backing store must be on another file system (or swap / memory).
   - The snapshot appears as a raw/block pseudo device. It is possible
     to freeze the unallocated blocks as well.
   - Number of snapshots is bound by the number of pseudo devices.
   - The snapshots get cleared on unmount.

The approach 1) has more features and will be more efficient. All changes
are inside the ffs functions. But it has be done for every file system
and for some "external" file systems like DOS or NTFS it is impossible.

Approach 2) is more generic. Every supported file system could be used.
It works better on nearly-full disks as the backing store doesn't need
any space on the snapshotted file system. It is possible to either snap
all blocks or only snap the allocated ones. It will not be very efficient
because it will copy-on-write more often than approach 1). Main changes
are:

   - A hook in spec_strategy to do the copy-on-write. This will not be
     expensive in terms of execution time.
   - A hook to destroy the snapshot on unmount.
   - May be a VFS_SNAPSHOT op to get a bitmap of allocated blocks.

Which one is better?
-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)