Re: [9fans] sanity check

Re: [9fans] sanity check

[Fco. J. Ballesteros]

: If you create a rio window and then you change
: the name space sitting under rio, the existing window's
: name space (which has already been copied from rio)
: doesn't inherit the new path.  So just re-binding things
: doesn't work as you might hope.

I'm not sure I understood correctly what you are trying
to do, but regarding re-binding things, it can be done by
using volfs (the port of Plan B volumes to Plan 9), there's
a working version that is a a little bit slow, and I'm
finishing now a more efficient version. You'll have to wait
a week or two to get a reliable veersion of the program.

The way to do it with volfs would be just to

echo $sysname #s/srvforcifs /cifs >/dev/vols
to declare your new volume named "/cifs", reacheable via 9P
at #s/srvforcifs.

and then 

mount -c /srv/vols /n/cifs /cifs

before starting rio, to get at /n/cifs whatever file server
is known as /cifs. Volfs takes care of rewriting fids to
match the new files found when it switches from one file tree
to another. This means that you don't have to
worry to update your binds. If you want to start a new tree,
you can rearrange your internal name space and restart.

/n/cifs would appear to be empty until you start your
program. When it becomes available, you'll get it in /n/cifs.
If you kill your program and start a new one, that one would
be mounted instead.

hth

Re: [9fans] sanity check

[Steve Simon]

Re PlanB.

I am still a little sketchy about what PlanB and volfs does exactly,
though its becomming clearer as I read more. I think you are right and
volfs might well make my life easier - somthing I look forward to :-)

-Steve

[9fans] sanity check

[Steve Simon]

Hi,

Playing with adding DFS support to my cifs client as and when
I get time.

DFS allows any path on a Windows server to be redirected to another
path on a different machine (and in theroy it could use another
protocol - CIFS, NFS, and NCP [netware] are defined).

To allow this dynamic remapping of namespace and optionally starting
a new client I plan to implement DFS as a layer [program] above cifs.

For efficency this translation should probably be done with a "clever"
algorithm (probably hash tables) and it occurs to me that I am about
to re-invent what the kernel already does.

Is it reasonable to do this mapping with a bind(2) call and let the
kernel take care of it. It might mean performing 10-50 extra binds,
is this an unresaonable load or a good use of kernel facilities?

Note: In my enviroment at least, I start cifs in my termrc behind rio
as much of my dialy work requires access to our windows servers. This
means an extended bind table will be in the namespace of everything
I use and so, if it slows things down, it will slow everything down.

-Steve

Re: [9fans] sanity check

[Russ Cox]

10-50 extra binds won't be noticed at all as far as
performance goes.  Unfortunately for you, they also
won't be noticed at all as far as rio goes.

If you create a rio window and then you change
the name space sitting under rio, the existing window's
name space (which has already been copied from rio)
doesn't inherit the new path.  So just re-binding things
doesn't work as you might hope.

This sort of thing comes up enough that I think it
would be nice if it did work (some new flag to rfork),
but it's not there now.

One quick and dirty option is to have cifs echo the
necessary bind commands to standard output (hopefully
cifs dissociates from the name space in which it is mounted)
and run something like:

  cifs | rc; srvfs dfs /n/cifs
  mount /srv/dfs /n/dfs

Then you will see the changes under /n/dfs because of the
extra exportfs (inside srvfs) mount combination.

Russ

Re: [9fans] sanity check

[Dave Eckhardt]

> If you create a rio window and then you change
> the name space sitting under rio, the existing window's
> name space (which has already been copied from rio)
> doesn't inherit the new path.  So just re-binding things
> doesn't work as you might hope.

This is why filename completion doesn't work if I
"9fs sources", right?  My shell's namespace has
something mounted in /n/sources, but rio's doesn't.

Contrariwise, if I plumb "Local 9fs sources" then
I can complete filenames which aren't actually in
my namespace unless I run the command inside the
window.

> This sort of thing comes up enough that I think
> it would be nice if it did work (some new flag to
> rfork), but it's not there now.

I'm not expert enough to make strong statements,
but it does sort of feel like something is wrong.
Maybe rfork() needs another namespace operation
in addition to copy/share/blank, something like
"copy on write", so that windows could have their
own devices but inherit additions to the "login
namespace" as they happen?

Dave Eckhardt

Re: [9fans] sanity check

[Steve Simon]

> 10-50 extra binds won't be noticed at all as far as
> performance goes.

Excellent.

>  cifs | rc; srvfs dfs /n/cifs
>  mount /srv/dfs /n/dfs

If I understand correctly this will not work with
DFS as you only get informed about DFS redirections in
CIFS as you hit them not at startup.

What I have done is to modify 9fs such that if you do
9fs xxx and /srv/xxx exists then 9fs just mounts xxx.

Thus if cifs is not running I can type 9fs dfs to connect to
dfs in "this" window, and plumb 'Local 9fs dfs' to export it to
all new windows. I usually close any idle windows and if there
is one or two I want to keep I just do 9fs dfs again in those
(and !9fs dfs in my sam window) to attach them.

I just live with this behavior it just seems reasonable to me -
but perhaps I am just used to it.

-Steve

Re: [9fans] sanity check

[rog]

> What I have done is to modify 9fs such that if you do
> 9fs xxx and /srv/xxx exists then 9fs just mounts xxx.

this is the default for 9fs entries that are not explicitly
dealt with (as implemented by srv(4)).

> Thus if cifs is not running I can type 9fs dfs to connect to
> dfs in "this" window, and plumb 'Local 9fs dfs' to export it to
> all new windows. I usually close any idle windows and if there
> is one or two I want to keep I just do 9fs dfs again in those
> (and !9fs dfs in my sam window) to attach them.
> 
> I just live with this behavior it just seems reasonable to me -
> but perhaps I am just used to it.

i use exportfs to provide an extra level of indirection
which gets around this awkwardness, providing a globally shared,
mutable namespace in /n.

i can plumb "Local 9fs dfs" and /n/dfs in all processes will contain
the newly acquired namespace. (actually i have a shell script,
named "local" which is this:

	#!/bin/rc
	plumb 'Local ' ^ $"*

[it's kind of ironic that it's named "local" when actually the desired
effect is a global one...]

thus in any window, i can do

	local 9fs sources

and plumb files /n/sources to any other preexisting
window (for example page). i find this extremely convenient.

unlike nemo's volfs (which i haven't actually looked at, i'm afraid),
this doesn't do automatic fid rewrites when the underlying space is
changed, but it is implemented from existing parts in only 4 lines of shell script,
and imposes negligible overhead.

the DFS scheme suggested earlier could be easily implemented by using
a variation on this scheme.

Re: [9fans] sanity check

[Federico Benavento]

> thus in any window, i can do
>
>         local 9fs sources

I use this too, it is in the  tip o' the day page.

http://www.cs.bell-labs.com/wiki/plan9/Tip_o'_the_day/index.html#PLUMBING%20TIPS

--
Federico G. Benavento