lkml.org 
[lkml]   [2004]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: unionfs
Date
From
=?iso-8859-1?Q?J=F6rn?= Engel <joern@wohnheim.fh-wedel.de> said:
> On Tue, 16 March 2004 12:04:30 -0400, Horst von Brand wrote:
> > Chris Friesen <cfriesen@nortelnetworks.com> 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?

Yes. Use it for a kernel tree (some 18.000 files by now), and do it each
time you mount it.

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

OK, let's see... I've got a laptop, on CD is the "original" kernel tree, on
HD is my modified stuff. I delete a file (or move it). Then I pack up, go
home. There I start up again. How is the fact that the file is gone recorded?

> > How do you back up a beast like this?
>
> - Use a really large tape (stupid).

All layers? Urgh...

> - cp /dev/... backup_medium
> - Backup software with a clue about the underlying fs.

Another special, non-POSIX piece that needs to be written and maintained.

> > 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 had my solution with _no_ kernel patch. Better still, it also works on
propietary Unix systems. Even better yet, any newbie Unix (even without any
Linux-with-funky-patch background) user understands what is going on here.
Fully POSIX compliant.

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

Not needed at all. Sure, if you have enough disk... now hand over the $2000

> - Copying the kernel tree is not just a question of space and money,
> but also about time.

And both copies slowly diverge, and need to be sychronized sometime. You
owe me another $2000

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

What you talking about is some kind of (modifiable) disk cache of data on
ro media...

> --
> Everything should be made as simple as possible, but not simpler.
> -- Albert Einstein

This stuff definitely fails this, IMHO.
--
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.070 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site