Miklos Szeredi <miklos@xxxxxxxxxx> writes:
> On Thu, 05 Mar 2009, Goswin von Brederlow wrote:
>> Miklos Szeredi <miklos@xxxxxxxxxx> writes:
>>
>> > On Wed, 04 Mar 2009, Goswin von Brederlow wrote:
>> >> Bernd and I ment the following scenario:
>> >>
>> >> /dev/sda1 /union/read-only
>> >> tmpfs /union/read-write
>> >>
>> >> with a delta-fs merging the two. Then running "echo foo >
>> >> /union/read-only/path/file" could be desasterous to your data.
>> >
>> > Well, if the writable branch is really meant to be a clone of the
>> > underlying fs, then yes. But writable unions are _not_ clones either,
>> > very far from that.
>>
>> The problem is that /delta-fs/path/file would suddenly be a composite
>> of the new file /union/read-only/path/file and any stored delta
>> information in /union/read-write/path/file of the old file.
>
> It can detect changes to the underlying file from the modification
> time (which it can store together with the delta).
But then what do you do? You don't know what changed and it is to late
to recover any data that might be lost.
> But having data deltas are in fact not even that interesting. Files
> are not often modified without being completely rewritten. Appending:
> that happens, but again that can be handled in an intelligent way by
> the delta layer.
>
> 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.
>> In unionfs-fuse files are currently always completly copy-up-ed when
>> modified. There a change of /union/read-only/path/file will give the
>> new file if it wasn't modified or the old modified file if it was. But
>> never mix the two.
>
> So? Some datasets may reside in multiple files, and inconsistencies
> could just as as well present themselves in that case.
>
> Thanks,
> Miklos
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
