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