On Fri, 06 Mar 2009, Goswin von Brederlow wrote: > > 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. No data has been lost. Or rather the data has been lost, when the underlying filesystem was modified. Oh, you didn't want that data to be lost? Why did you overwrite it then? See? All the data is there: the changes you made to the file are there in the delta, and the underlying file is still there too, we just didn't preserve the old version, but this is not what deltafs is about, and it's not what unionfs is about either. What to do about such a situation? It's a policy decision, it could - return the underlying file and ignore the delta - ignore the changes made to the underlying file and mechanically merge the delta (possibly resulting in inconsistencies). - return an error (EIO or ESTALE) In addition the user might have the option to merge the delta by hand, this should be much easier than trying to merge two files, where you know _nothing_ about the changes themselves. In fact the delta format might not even want to implement data deltas, or they could be made optional, or configurable per file. Whatever. > > 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 -- 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
