On Saturday 28 February 2009, Goswin von Brederlow wrote: > Miklos Szeredi <miklos@xxxxxxxxxx> writes: > > Here is my first try at a "delta" filesystem. It takes two > > directories, one of which is a read-only base, and the other is where > > the differences are stored. It stores data, metadata and directory > > modifications without copying up whole files from the read-only > > branch. > > > > The layout of the delta store may look similar to the writable branch > > of a union fs, but this is basically just coincidence (it was easier > > to start out this way). > > > > Currently it's implemented with fuse and it's not optimized at all, so > > performance may suck in some cases. But I think this is a useful > > concept and a better model, than trying to fit writable branches into > > a union filesystem. > > > > Comments, bug reports are welcome. > > > > Thanks, > > Miklos > > Wouldn't it make more sense to start with unionfs-fuse and add a delta > feature to it? unionfs-fuse already has all you need except that it > will copy the whole file (if on a read-only branch) on write. Well yes, but it would need to be configurable by the user. IMMHO, the 'delta' ansatz has a big problem - what happens if the admin decides to modify the underlying ro-branch, which is a distribution chroot seen by all clients as their '/'? Any time files may be modified or even deleted on this branch when the admin does an update. This is also the exactly the problem why none of the kernel unionfs implementation fits my needs and why I started to work on unionfs-fuse. Only, the delta approach makes it even worse ;) Cheers, Bernd -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
