Re: [fuse-devel] delta filesystem prototype

[Goswin von Brederlow <goswin-v-b@web.de>]

Miklos Szeredi <miklos@szeredi.hu> writes:

> On Fri, 06 Mar 2009, Goswin von Brederlow wrote:
>> > The most interesting is the directory and metadata deltas, which do
>> > make a delta-fs like implementation much more effective and nicer as a
>> > dumb union type filesystem.  Mind, unionfs and aufs are rapidly
>> > acquiring non-union traits, like inode number storage, virtual hard
>> > links (not to speak of whiteouts).  Which makes them all the more
>> > hackish, I much prefer a conceptually clean solution.
>> 
>> That is certainly something for unionfs-fuse as far as it isn't done
>> already. Doesn't even need any delta algorithm, just seperate storage
>> of metadata and normal data. Iirc Bernd already did look into
>> preserving inodes in unionfs-fuse.
>
> At which point it's less of a union and more of a delta.  A union is
> taking two ordinary plain filesystems and merging them according to
> some rules.  A delta is having a plain filesystem and merging a
> special format one into this.  See where I'm going?
>
> My main question in all this is: does it make sense to keep the union
> semantics and tack on various features into separate storage?  Or is
> it better to abandon the unioning altogether in favor of a more
> efficient delta format?
>
> Thanks,
> Miklos

The union should be transparent to the user and applications. The
problem is that some application do look at the inode number,
m/a/ctime and so on. So to be transparent the metadata has to be
handled in a union as well. If you want to call it a delta filesystem
then fine. I would expect a delta filesystem to do deltaing of file
content though, not just be able to track metadata changes seperate
from file data. But that is nothing to fight over.

MfG
        Goswin