On Wed, 22 Oct 2003, Jason Thorpe wrote:
> 	- 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.

This reminds me of some layered file systems that I wish somebody would
implement: migretefs and mirrorfs.  Both would work a lot like unionfs,
with the following differences:

migratefs:
        A background task moves files from the lower layer to the upper
        layer;
	Updates are reflected only in the upper layer;
        Eventually, the lower layer will be empty, and everything that
        used to be in the lower layer will be in the upper layer;
        When the above state is reached, the background task will
        terminate.

mirrorfs:
        A background task copies files from the upper layer to the lower
        layer;
        Depending on a mount option, updates are reflected only in the
        upper layer, or in both layers;
        Eventually, (depending on the mount option) the lower layer will
        be a static snapshot of what the upper layer looked like at
        the time the mount was performed, or the lower layer will be a
        continuously updated copy of the upper layer;
        When the above state is reached, the background task will
        terminate.

--apb (Alan Barrett)