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

Stefan
> 
> 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
> tsarna@endicor.com        up to cowboys as role models. And vice versa."
> 


-- 
Stefan Grefen                          Convex Computer GmbH, Frankfurt, Germany
grefen@convex.com		       Phone: +49-69-665270


------------------------------------------------------------------------------