Subject: Re: path component substitutions (was diskless booting)
To: Ty Sarna <firstname.lastname@example.org>
From: Stefan Grefen <email@example.com>
Date: 03/15/1994 12:12:10
> Stefan Grefen wrote:
> > Please not again. I admit this stuff is useful, but I hate to think
> > about the consequences for let's say a backup.
> Huh? There are no consequences for a backups. I'm not sure you have an
> accurate understanding of how the @substitiion stuff works.
> > How is xy.@sys handled? As a symlink it wouldn't break anything, but as
> xy.@sys where? You mean a directory entry called "xy.@sys"? A symlink
> pointing to xy.@sys? or accessing xy.@sys and getting xy.arch_os123?
> > a normal entry in the filesystem you would backup one of these twice, or as
> > a link (but that would introduce links to directories and I'm sure these
> > will break at least find (it would traverse it twice) ...).
> You don't have to back up twice. If your /usr/local looks like:
Sorry, than I got something wrong in a previous post, I assumed that it was
not working through symlinks. These kind of conditional symlinks is
useful, but than I don't understand why it doesn't work with NFS.
But still I think it's something that shouldn't be in the kernel (I know
it could start a religious war now ...). It's a special case of a more
general feature, inodes which have different meanings in different
circumstances. There should be a general mechanism to deal with that
(eg. callout to a daemon) because there are a lot of features that could
be implemented that way ( file migration, file generations , NFS caching , ...
location dependencies (keyword mobile computing..)). Often used inodes
would stay cached in the kernel, so the overhead should be minimal.
> > A more generic solution would be to implemented something like SUN's TFS.
> > NETBSD's lofs could be good starting point for that.
> That's no more generic. Either way, you're required to add something to
> the system that currently doesn't exist, right? :-)
But you can use it to have source on a readonly medium (CDROM, ro mounted
filesystem) and do a compile with out building a symlink tree first.
> Besides, the @substitutions are in wide use in AFS and in OSF's DFS, and
> work very very well in practice. They've also been implemented and used
> on a much wider range of systems than TFS has, since TFS is a
> Sun-specific thing.
I know, (masscomp springs to mind here ...) but it was sometimes a nightmare
educating the users why they couldn't find there file right now ...
> > PS. I volunteer for the TFS code as soon as my logical volume manager is
> > finished. (that should be in the near future (2-4 weeks) as I get a decent
> > notebook one of the next days)
> Great! TFS is useful for many things, I just don't think this is one of
> them (particularly the original case that restarted this discussion --
> TFS wouldn't work there).
Of course it would. You just use a different obj. filesystem for each
> At any rate, I didn't mean to stir up so much discussion... I still want
> to hear discussion on the diskless boot architecture. :-)
> Ty Sarna "As you know, Joel, children have always looked
> firstname.lastname@example.org up to cowboys as role models. And vice versa."
Stefan Grefen Convex Computer GmbH, Frankfurt, Germany
email@example.com Phone: +49-69-665270