[9fans] cdrom floppy tape etc, media mount point

[9fans] cdrom floppy tape etc, media mount point

[okamoto]

This is not so important, I know. However it annoyes me offen, particularly
when I need to explain it to newbies.  I remember some discussions
were undertaken here before, but I don't see the difference in the 
new release.  I suppose none did not pay attention so much to this.  :-)

/n is for mount points of file trees from network.   
/mnt is for mount points of user level file severs.

Then, where can we put local floppy(a:, b: etc.) or disks other than
kfs filesystem?   If we could have another directory such as /media
or just /m, we can push out all the local stuffs into it.   Even if those
are imported from network, the name of m or media will not suffer 
from unmatched naming.  Then, we don't need /mnt/cd, either.
This does not deny to have those names under /n, of course.   
However it may annoy many of newbies.

Then, /m could have directories of
9
9fat
a:
b:
c:
d:
cd
tapefs
boot
kfs

What is for a, b, c, by the way?

Kenji

Re: [9fans] cdrom floppy tape etc, media mount point

[Don]

Who cares.

Re: [9fans] cdrom floppy tape etc, media mount point

[Russ Cox]

[-- Attachment #1: Type: text/plain, Size: 277 bytes --]

> What is for a, b, c, by the way?

Sorry to prolong this, but I don't see an
answer to this part of the message.

/n/a, /n/b, and /n/c are used by a:, b:, and c:,
which now mount on both /n/_: and /n/_.  
the colon-less mountpoint is easier for acme
and the plumber.

[-- Attachment #2: Type: message/rfc822, Size: 2236 bytes --]

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: [9fans] cdrom floppy tape etc, media mount point
Date: Fri, 12 Jul 2002 11:07:28 +0900
Message-ID: <20020712020804.559A419A1C@mail.cse.psu.edu>

This is not so important, I know. However it annoyes me offen, particularly
when I need to explain it to newbies.  I remember some discussions
were undertaken here before, but I don't see the difference in the 
new release.  I suppose none did not pay attention so much to this.  :-)

/n is for mount points of file trees from network.   
/mnt is for mount points of user level file severs.

Then, where can we put local floppy(a:, b: etc.) or disks other than
kfs filesystem?   If we could have another directory such as /media
or just /m, we can push out all the local stuffs into it.   Even if those
are imported from network, the name of m or media will not suffer 
from unmatched naming.  Then, we don't need /mnt/cd, either.
This does not deny to have those names under /n, of course.   
However it may annoy many of newbies.

Then, /m could have directories of
9
9fat
a:
b:
c:
d:
cd
tapefs
boot
kfs

What is for a, b, c, by the way?

Kenji

Re: [9fans] cdrom floppy tape etc, media mount point

[Jack Johnson]

>>thus, having done:
>>
>>	autodir /n
>>
>>you can do, say:
>>
>>	mount /srv/factotum /n/bletheridoo

I was thinking about this last night on the drive home.

Though I realize things will probably change with the new fileserver, I 
was thinking about how to get dump functionality from venti as-is.  It 
occurred to me that one should be able to do something like:

vac -svf $home/vac/`{date -n} -h ventiserver /n/hullabaloo

run via cron, then have a variation on autodirfs that rebuilds the 
directory trees dump-style (or some custom style: 2002/Feb/20) based on 
the contents of $home/vac, and calls vacfs when traversing to the 
appropriate date.

(tangent ahead -- leave while you can)

My mind then started wandering to a coat-check style Web service where 
you'd post a file or set of files and vac would return a "ticket" so you 
could retrieve it later.  Maybe your resume that you only use once a 
decade, or some file you'd like to share with friends that lies 
somewhere in between needing security and being public information.

It also reminded me of the work done at PARC with small handheld devices 
called PARCTABs that have minimal storage, running much like a Plan 9 
terminal.  One thing I remember reading about them is that they were 
designed so people could treat them as if they had storage, so you could 
drag documents to the Tab, walk down the hall and copy them to another 
workstation, workboard, etc.  In reality, the data never moved, but the 
representation of the data behaved as if it did, just like icons for 
files on a local hard drive.

The part that makes me smile the most in Sean's paper is where he says, 
"For a user, it appears that vac compresses any amount of data down to 
45 bytes."  I think my wristwatch will hold 45 bytes.  I can only 
imagine how many vac fingerprints a cell phone could hold.  Where vac 
fingerprints are more powerful than PARCTABs, in my opinion, is that 
they're not tied to the network, per se.  Fingerprints can be stored on 
flash media and popped in a pocket, written on a 3x5 index card and 
dropped in the mail, kept on a USB keychain, sent via pager, etc.

With a vacfs port to Inferno and the Inferno IE plug-in (or vacfs 
support like WebDAV), you might be able to utilize vac URLs like 
vac://hullabaloo/64daefaecc4df4b5cb48a368b361ef56012a4f46.  I think it 
would/will be fun to experiment with vac fingerprints as tickets for 
data using extremely small, cheap devices or Web interfaces or 
combinations of the two, along the same lines as Sean's idea of 
implementing SFSRO on top of venti.

All of this, of course, for read-only data.

I also wonder if there might be a convenient way to do chaffing and 
winnowing using a venti archive, given the amalgam of blocks.

Sorry for the blather.  I'm prone to it.

-Jack

Re: [9fans] cdrom floppy tape etc, media mount point

[rog]

[-- Attachment #1: Type: text/plain, Size: 324 bytes --]

> >i recently knocked up a little filesystem as in inferno as an
[...]
> Care to share your code with us?

sure.

it won't do you much good though, as the support modules don't exist
under the current version of inferno (and aren't compatible either).
still, it might be of interest to some.

attached.

  rog.

[-- Attachment #2.1: Type: text/plain, Size: 309 bytes --]

The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Disposition: attachment; filename=autodir.b
	Content-Type: text/plain; charset="US-ASCII"
	Content-Transfer-Encoding: 7bit

[-- Attachment #2.2: autodir.b.suspect --]
[-- Type: application/octet-stream, Size: 3169 bytes --]

implement Tst;
include "sys.m";
	sys: Sys;
include "draw.m";
include "styx.m";
	Rmsg: import Styx;
include "styxservers.m";
	styxservers: Styxservers;
	Ebadfid, Enotfound, Eexists, Eperm: import Styxservers;
	Styxserver, Filetree, readbytes: import styxservers;
include "simplefs.m";
	simplefs: SimpleFS;
	Fs: import simplefs;

Tst: module {
	init: fn(nil: ref Draw->Context, argv: list of string);
};

Qroot: con big 16rfffffff;

badmodule(p: string)
{
	sys->fprint(sys->fildes(2), "cannot load %s: %r\n", p);
	sys->raise("fail:bad module");
}
DEBUG: con 0;

refcounts := array[10] of int;

init(nil: ref Draw->Context, nil: list of string)
{
	sys = load Sys Sys->PATH;
	styxservers = load Styxservers Styxservers->PATH;
	if (styxservers == nil)
		badmodule(Styxservers->PATH);
	styxservers->init();
 
	simplefs = load SimpleFS SimpleFS->PATH;
	if (simplefs == nil)
		badmodule(SimpleFS->PATH);
	simplefs->init();

	(fs, fsop) := simplefs->start();
	(tchan, srv) := Styxserver.new(sys->fildes(0), Filetree.new(fsop), Qroot);

	fs.create(Qroot, dir(".", Sys->DMDIR | 8r555, Qroot));

	for (;;) {
		gm := <-tchan;
		if (gm == nil) {
			fs.quit();
			exit;
		}
		e := handlemsg(gm, srv, fs);
		if (e != nil)
			srv.reply(ref Rmsg.Error(gm.tag, e));
	}
}

handlemsg(gm: ref Styx->Tmsg, srv: ref Styxserver, fs: ref Fs): string
{
	pick m := gm {
	Walk =>
		# allow walk to any name from root, otherwise nothing.
		# if name did not already exist, we create it and refcount it.
		if (m.name == "..") {
			c := srv.getfid(m.fid);
			if (c != nil && c.qid != Qroot)
				decref(c.qid, fs);
			srv.walk(m);
			return nil;
		}

		c := srv.getfid(m.fid);
		if (c == nil)
			return Ebadfid;
		if (c.qid != Qroot)
			return Enotfound;
		(d, nil) := srv.t.walk(Qroot, m.name);
		if (d == nil)
			d = addentry(m.name, fs);
		else
			incref(c.qid);
		c.isdir = d.qid.qtype & Sys->QTDIR;
		c.qid = d.qid.path;
		srv.reply(ref Rmsg.Walk(m.tag, m.fid, d.qid));
	Clone =>
		c := srv.clone(m);
		if (c != nil && c.qid != Qroot)
			incref(c.qid);
	Clunk =>
		c := srv.clunk(m);
		if (c != nil && c.qid != Qroot)
			decref(c.qid, fs);
	* =>
		srv.default(gm);
	}
	return nil;
}

addentry(name: string, fs: ref Fs): ref Sys->Dir
{
	for (i := 0; i < len refcounts; i++)
		if (refcounts[i] == 0)
			break;
	if (i == len refcounts) {
		refcounts = (array[len refcounts * 2] of int)[0:] = refcounts;
		for (j := i; j < len refcounts; j++)
			refcounts[j] = 0;
	}
	d := dir(name, Sys->DMDIR|8r555, big i);
	fs.create(Qroot, d);
	refcounts[i] = 1;
	return ref d;
}

incref(q: big)
{
	id := int q;
	if (id >= 0 && id < len refcounts)
		refcounts[id]++;
}

decref(q: big, fs: ref Fs)
{
	id := int q;
	if (id >= 0 && id < len refcounts)
		if (--refcounts[id] == 0)
			fs.remove(big id);
}

Blankdir: Sys->Dir;
dir(name: string, perm: int, qid: big): Sys->Dir
{
	d := Blankdir;
	d.name = name;
	d.uid = "me";
	d.gid = "me";
	d.qid.path = qid;
	if (perm & Sys->DMDIR)
		d.qid.qtype = Sys->QTDIR;
	else
		d.qid.qtype = Sys->QTFILE;
	d.mode = perm;
	return d;
}

Re: [9fans] cdrom floppy tape etc, media mount point

[Ben]

>i recently knocked up a little filesystem as in inferno as an
>experiment (it was actually to test a new library interface), which
>acts as a kind of auto mountpoint directory.
>
>in this directory, a walk to any name will succeed, and will walk to
>an empty directory of that name.  a read of the original will now show
>the new name.
>
>thus, having done:
>
>	autodir /n
>
>you can do, say:
>
>	mount /srv/factotum /n/bletheridoo
>
>and it will work - the destination mount point is created on demand
>(and deleted when there are no more references to it).
>
>i haven't used it in earnest, but it always seemed a bit unnatural
>to have to pre-create mount points for all future services;
>perhaps there's a place for something like this under plan 9?
>(it's only a couple of hours work).
>
>  cheers,
>    rog.
>

Care to share your code with us?

Re: [9fans] cdrom floppy tape etc, media mount point

[rog]

> If you make a directory mode 0777 they you have no say about what
> silly users will put in it (or take out of it), but you can be sure
> (by hypothesis) that you won't like it.  That's why Plan 9 doesn't have
> a world writable /tmp.

oh i see.
you are assuming, however, that /n is implemented on a file server.
on some systems, i've seen it implemented as part of #/ (i.e.  read
only - requires a kernel build to add to it).

i quite like the garbage-collected nature of autodir; between them /n
and /mnt have 52 entries in them on this system and, checking in a rio
window, only 7 are in use.

being able to ls /n and see what mountpoints have been used in this
session seems quite useful; and it means i'd feel no compunction about
doing something like:

	for (i in $manyftpservers) {
		ftpfs -a me@home -m /n/ftp.$i $i
	}

oh yes, autodir also means i don't have to worry about doing the mkdir
first, which means i can just run the usual programs and they can
blithely mount themselves. that's possibly its main advantage.

  cheers,
    rog.

Re: [9fans] cdrom floppy tape etc, media mount point

[Scott Schwartz]

If you make a directory mode 0777 they you have no say about what
silly users will put in it (or take out of it), but you can be sure
(by hypothesis) that you won't like it.  That's why Plan 9 doesn't have
a world writable /tmp.

Re: [9fans] cdrom floppy tape etc, media mount point

[rog]

> But it does matter if someone fills it up with big files.

but you're not filling it up with big files... you're just
using it for a mount point!

unless i'm misunderstanding something horribly.

Re: [9fans] cdrom floppy tape etc, media mount point

[Scott Schwartz]

| the difference between mode 0777 /tmp and /n is that in /n clashes
| don't matter! (all you want is a name, so it doesn't matter who
| created it).

But it does matter if someone fills it up with big files.

Re: [9fans] cdrom floppy tape etc, media mount point

[Sam]

I was wondering about this post too.  If autodir mounts into the
per process namespace, it'd be awful difficult for "someone"
to fill it up, unless that someone is the mounter, eh?

Sam

On Tue, 16 Jul 2002 rog@vitanuova.com wrote:

> > But it does matter if someone fills it up with big files.
>
> but you're not filling it up with big files... you're just
> using it for a mount point!
>
> unless i'm misunderstanding something horribly.
>

Re: [9fans] cdrom floppy tape etc, media mount point

[rog]

> Any process that wanted a mount point in /n could just create it,
> execpt that you don't want to reinvent mode 0777 /tmp.  In that light,
> /n might make sense if it was the union of /mnt/n and $home/mnt/n.
> As an added bonus, I've just invented a reason to keep /mnt!

the difference between mode 0777 /tmp and /n is that in /n clashes
don't matter! (all you want is a name, so it doesn't matter who
created it).

Re: [9fans] cdrom floppy tape etc, media mount point

[Martin C.Atkins]

On Mon, 15 Jul 2002 17:45:38 +0100 rog@vitanuova.com wrote:
>..
> i haven't used it in earnest, but it always seemed a bit unnatural
> to have to pre-create mount points for all future services;
> perhaps there's a place for something like this under plan 9?
> (it's only a couple of hours work).
> 
>   cheers,
>     rog.
> 

I assume that this is much of the reason why resources are usually
union-bound to /net or /dev (for example), when they might more
logically have been mounted directly on to /dev/X, or /net/Y?

Martin
-- 
Martin C. Atkins	martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.

Re: [9fans] cdrom floppy tape etc, media mount point

[Fco.J.Ballesteros]

> and it will work - the destination mount point is created on demand
> (and deleted when there are no more references to it).

That's great. It would be a neat companion to the
automatic mounts I'm using these days, because right now
I'm mounting resources advertised at prearranged mount points,
but it'd be better to keep them also at /n.

Anyone implementing autodir?

Re: [9fans] cdrom floppy tape etc, media mount point

[Scott Schwartz]

On Mon, Jul 15, 2002 at 05:45:38PM +0100, rog@vitanuova.com wrote:
> i haven't used it in earnest, but it always seemed a bit unnatural
> to have to pre-create mount points for all future services;

Any process that wanted a mount point in /n could just create it,
execpt that you don't want to reinvent mode 0777 /tmp.  In that light,
/n might make sense if it was the union of /mnt/n and $home/mnt/n.
As an added bonus, I've just invented a reason to keep /mnt!

Re: [9fans] cdrom floppy tape etc, media mount point

[Lucio De Re]

On Mon, Jul 15, 2002 at 05:45:38PM +0100, rog@vitanuova.com wrote:
> 
> thus, having done:
> 
> 	autodir /n
> 
> you can do, say:
> 
> 	mount /srv/factotum /n/bletheridoo
> 
> and it will work - the destination mount point is created on demand
> (and deleted when there are no more references to it).
> 
This ceryainly has _my_ vote.

> i haven't used it in earnest, but it always seemed a bit unnatural
> to have to pre-create mount points for all future services;
> perhaps there's a place for something like this under plan 9?
> (it's only a couple of hours work).
> 
Brilliant, if only because I was considering the problem and didn't
have the perspicacity to see such an elegant solution!

++L

Re: [9fans] cdrom floppy tape etc, media mount point

[rog]

> >The /n vs /mnt thing is just a convention.
> 
> Yes, I know it.  However, it's not easy to explain this to my naive
> students.  
> You, probably  many others?, don't want to have many directory 
> in /, don't you?

personally, i'd like to get rid of /mnt entirely.  i much prefer it
when things are in /n, mainly because it's so much easier to type!

i recently knocked up a little filesystem as in inferno as an
experiment (it was actually to test a new library interface), which
acts as a kind of auto mountpoint directory.

in this directory, a walk to any name will succeed, and will walk to
an empty directory of that name.  a read of the original will now show
the new name.

thus, having done:

	autodir /n

you can do, say:

	mount /srv/factotum /n/bletheridoo

and it will work - the destination mount point is created on demand
(and deleted when there are no more references to it).

i haven't used it in earnest, but it always seemed a bit unnatural
to have to pre-create mount points for all future services;
perhaps there's a place for something like this under plan 9?
(it's only a couple of hours work).

  cheers,
    rog.

Re: [9fans] cdrom floppy tape etc, media mount point

[okamoto]

Hi rog!

I'm very very glad to see your solution to my problem.
I like this mailing-list, because someone always can invent
something new idea when it is neccessary.

'auto mountpoint directory', yeah!, it's that I wanted!
So, we can wipe out difficult explanation to our newbies.

I also like Scott's union directory of /n.
Thanks all, and I'll wait those ideas will be incorporated to
the sources.

At last, summer vacation season is comming here.☺

Thnaks all!

Kenji   --now testing Release 4 mail system from our new network...

Re: [9fans] cdrom floppy tape etc, media mount point

[Sam]

I'll second this.  Very neat.

On Mon, 15 Jul 2002 rog@vitanuova.com wrote:

> > >The /n vs /mnt thing is just a convention.
> >
> > Yes, I know it.  However, it's not easy to explain this to my naive
> > students.
> > You, probably  many others?, don't want to have many directory
> > in /, don't you?
>
> personally, i'd like to get rid of /mnt entirely.  i much prefer it
> when things are in /n, mainly because it's so much easier to type!
>
> i recently knocked up a little filesystem as in inferno as an
> experiment (it was actually to test a new library interface), which
> acts as a kind of auto mountpoint directory.
>
> in this directory, a walk to any name will succeed, and will walk to
> an empty directory of that name.  a read of the original will now show
> the new name.
>
> thus, having done:
>
> 	autodir /n
>
> you can do, say:
>
> 	mount /srv/factotum /n/bletheridoo
>
> and it will work - the destination mount point is created on demand
> (and deleted when there are no more references to it).
>
> i haven't used it in earnest, but it always seemed a bit unnatural
> to have to pre-create mount points for all future services;
> perhaps there's a place for something like this under plan 9?
> (it's only a couple of hours work).
>
>   cheers,
>     rog.
>

Re: [9fans] cdrom floppy tape etc, media mount point

[Ben]

> Anything serviced by the mount driver is actually a remote file
> system. This includes servers reached through /srv mostly.
> The only local file systems are those of the kernel drivers.
> 

I agree, as technically, one should be able to mount HD's and maybe
even floppies from other systems, and use them the same as if they
were part of the computer the user is sitting at.  It would become
confusing (and not very Plan 9-like) to have to remember that /n/c: is
a remote HD and /mnt/c: is local, etc.  It seems that just using union
directories, one could bind both a remote and local HD onto /n/c:, and
everything is more transparent, to both programs and the user.  Not to
mention it's just plain easier to remember!

Re: [9fans] cdrom floppy tape etc, media mount point

[anothy]

your re-definition of "remote" to make things like floppys and
tapes fit there is interesting. but my issues is rather with
"systems" - i tend strongly to think that's refering to, y'know,
systems. boxes. computers. i imagine an entry in /n for each
box on the network you care about reaching, and that's it.
everything else i'd probably put in /mnt. this use of /n also
matches my understanding of its historical origin - am i
correct on this?

and for those of you who're wondering why any of this
matters... well, it's questionable whether it does. but there
certainly is value to having the file system as cleanly
organized as possible. there are other places that could use
cleaning up, too: /lib vs. /sys/lib, source for acme programs
under /acme (or maybe just /acme itself)... but i doubt any
of these are really worth spending much time on unless the
folks at the Labs express some interest (which i doubt -
they've got day jobs and better things to be doing, thankfully).
ア

Re: [9fans] cdrom floppy tape etc, media mount point

[okamoto]

>The /n vs /mnt thing is just a convention.

Yes, I know it.  However, it's not easy to explain this to my naive
students.  
You, probably  many others?, don't want to have many directory 
in /, don't you?

Kenji

Re: [9fans] cdrom floppy tape etc, media mount point

[Fco.J.Ballesteros]

Yes, but where did the old file come from?
If it was remote, it's still remote when bound.

In any case, all this probably depends on the point of view.
What matters is that you can be happy no matter the location
of the file. The /n vs /mnt thing is just a convention.

Re: [9fans] cdrom floppy tape etc, media mount point

[okamoto]

According to my understanding, we can use bind(1) when old file
or directory is already there .  So, they are there in the kernel.
Am I wrong?

kenji

Re: [9fans] cdrom floppy tape etc, media mount point

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 342 bytes --]

This is what I tell my students:

Anything serviced by the mount driver is actually a remote file
system. This includes servers reached through /srv mostly.
The only local file systems are those of the kernel drivers.

Thus, you can see file trees from your disks and other machines
as remote things that you can import to your system.

[-- Attachment #2: Type: message/rfc822, Size: 1493 bytes --]

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] cdrom floppy tape etc, media mount point
Date: Fri, 12 Jul 2002 19:15:02 +0900
Message-ID: <20020712101539.0118519AAB@mail.cse.psu.edu>

>since the media can be considered
>as a `remote system'. 

/rc/bin/termrc says:

	for(i in f t m L S A)
		/bin/bind -a '#'^$i /dev >/dev/null >[2=

So, you mean kernel devices are also 'remote systemes'?
Media, of course, can be imported from remote system.

How do you explain this to your students?

kenji

Re: [9fans] cdrom floppy tape etc, media mount point

[okamoto]

>since the media can be considered
>as a `remote system'. 

/rc/bin/termrc says:

	for(i in f t m L S A)
		/bin/bind -a '#'^$i /dev >/dev/null >[2=

So, you mean kernel devices are also 'remote systemes'?
Media, of course, can be imported from remote system.

How do you explain this to your students?

kenji

Re: [9fans] cdrom floppy tape etc, media mount point

[Fco.J.Ballesteros]

 From namespace(4):

         /mnt          A directory containing mount points for appli-
                        cations.  /mnt/factotum Mount point for
                        factotum(4).
          /n            A directory containing mount points for file
                        trees imported from remote systems.

Thus I think /n/a: is the right place, since the media can be considered
as a `remote system'. 

Re: [9fans] cdrom floppy tape etc, media mount point

[okamoto]

Yes, put all those in /mnt may be one choice.
This is beacuse those are the mounting points of one of user level 
file servers, too.

I thought in this line an example of /mnt/cd, (probably put by Russ?).
Here, he may thought it has a particular function not only for files,
but also make sounds, then, it should be onto /mnt file sever point.
Most importantly, it could not imported from another machine.
Of in that case, sounds are coming from another machine.  ^_^
But I'm not Russ, anyway.

I supposed the reason why a: or 9fans etc are put in /n is that they
shows just file trees as others imported from network.  However,
files under /mnt have some function to do, and usually for the file
server running on the machine.   In Plan 9 all the resources are files, 
yes, it's true.   However...

This is the reason why I proposed to make /m or /media directory.

Kenji

Re: [9fans] cdrom floppy tape etc, media mount point

[anothy]

// /mnt is for mount points of user level file severs.
[and then later]
// ...where can we put local floppy... ...or disks other than
// kfs filesystem?

to answer this question, i'd simply point out that "local disks"
already show up in /dev - since they're devices. interpreting
their contents, like turning bits on a disk into a file system,
is done by (you guesed it) a user level file server (okay, i
guess things like kfs sometimes show up in the kernel, but that's
the exception). so i say put 'em all in /mnt.

yes, i do suggest moving things like /n/a: to /mnt/a: for the
sake of consistency and clarity.
ア