Re: unionfs

[Jörn Engel]

On Tue, 16 March 2004 12:04:30 -0400, Horst von Brand wrote:
> Chris Friesen <cfriesen@xxxxxxxxxxxxxxxxxx> said:
> 
> > 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.

Correct.  Is that a problem?

> > 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?

What happens if I write to /dev/hda while having my rootfs /dev/hda1?
Bad things, damn right.  But why would anyone do that?

Can you tell me what the point behind your examples is?  It escapes
me.

> How do you back up a beast like this?

- Use a really large tape (stupid).
- cp /dev/... backup_medium
- Backup software with a clue about the underlying fs.

> 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.

Great, so you found *your* solution already.  I've done the same
without the need for symlinks in a 90-line patch, good enough for my
immediate needs right now.  But someday I'd like to have the remaining
10% as well. :)

> > 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.

Not true:
- Even with bitkeeper, people copy their complete tree before making
changes, at least Linus sais he does.  Go back to start, do not
collect $2000.
- Copying the kernel tree is not just a question of space and money,
but also about time.
- When the time and disk hit of identical copies approaches zero,
people will do this a lot more, they have new possibilities.  *That*
is really important, not doing the same as before, just slightly
optimized.

Jörn

-- 
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-
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/