Re: unionfs

[Horst von Brand]

Chris Friesen <cfriesen@xxxxxxxxxxxxxxxxxx> said:
> Horst von Brand wrote:
> > Assuming one RW on top of a RO only now: What should happen when a
> > file/directory is missing from the top? If the bottom one "shows through",
> > you can't delete anything; if it doesn't, you win nothing (because you will
> > have to keep a complete copy RW on top).

> I don't see how you win nothing.  I create an overlay filesystem. 
 
Completely empty is what you get then... and you have to explicitly link in
each file. Or everything shows up here.
 
>                                                                   I 
> delete a bunch of files in the overlay and it doesn't show through. 

Next time you mount it, what happens? How do you know the "top files" where
deleted, and should not show up? 

What happens if I mount the live 2.6.4 kernel source over a CD containing
2.5.30? What happens to identical files, files that moved, changed files,
deleted files? Pray tell, how does the kernel find out which is which?

How do you back up a beast like this?
 
>                                                                     All 
> my other files are still links to the originals, with the

Something missing here?

In any case, there are tools that create a farm of symlinks, and when you
try to write to a file (pointing to a RO area/file), you get an error. This
gives you 90% of what you want, _without_ aggravating the filesystem
hackers.

> I would dearly love to use something like to make it easy to track 
> changes made all over a source tree.  If I could sync them up at the 
> begining, then make all my changes in the overly, then doing a diff is 
> really easy since you just look for places where the inodes are 
> different between the two filesystems.  Like having hard links, but the 
> filesystem breaks them for you when you write.

This is called BitKeeper, CVS, Subversion, arch, RCS, SCCS, ... Better yet,
it keeps the history of each file (not just the one version on RO media),
with annotations. You decide when a version is ready for archiving.

Sure, this would save disk space. But at today's prices, it just is not
worth the trouble.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/