Miklos Szeredi <miklos@xxxxxxxxxx> 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
--
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
