9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] cdrom floppy tape etc, media mount point
@ 2002-07-12  2:07 okamoto
  2002-07-12  9:03 ` Don
  0 siblings, 1 reply; 29+ messages in thread
From: okamoto @ 2002-07-12  2:07 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
  2002-07-12  2:07 [9fans] cdrom floppy tape etc, media mount point okamoto
@ 2002-07-12  9:03 ` Don
  0 siblings, 0 replies; 29+ messages in thread
From: Don @ 2002-07-12  9:03 UTC (permalink / raw)
  To: 9fans

Who cares.


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
@ 2002-07-30 11:45 Russ Cox
  0 siblings, 0 replies; 29+ messages in thread
From: Russ Cox @ 2002-07-30 11:45 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
  2002-07-18  9:50 ` Ben
@ 2002-07-18 16:06   ` Jack Johnson
  0 siblings, 0 replies; 29+ messages in thread
From: Jack Johnson @ 2002-07-18 16:06 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
@ 2002-07-18 11:19 rog
  0 siblings, 0 replies; 29+ messages in thread
From: rog @ 2002-07-18 11:19 UTC (permalink / raw)
  To: 9fans

[-- 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;
}

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
  2002-07-16 13:34 rog
  2002-07-16 15:19 ` Scott Schwartz
@ 2002-07-18  9:50 ` Ben
  2002-07-18 16:06   ` Jack Johnson
  1 sibling, 1 reply; 29+ messages in thread
From: Ben @ 2002-07-18  9:50 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
@ 2002-07-16 16:09 rog
  0 siblings, 0 replies; 29+ messages in thread
From: rog @ 2002-07-16 16:09 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
  2002-07-16 15:35 rog
  2002-07-16 14:42 ` Sam
@ 2002-07-16 15:39 ` Scott Schwartz
  1 sibling, 0 replies; 29+ messages in thread
From: Scott Schwartz @ 2002-07-16 15:39 UTC (permalink / raw)
  To: 9fans

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.


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
@ 2002-07-16 15:35 rog
  2002-07-16 14:42 ` Sam
  2002-07-16 15:39 ` Scott Schwartz
  0 siblings, 2 replies; 29+ messages in thread
From: rog @ 2002-07-16 15:35 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
  2002-07-16 13:34 rog
@ 2002-07-16 15:19 ` Scott Schwartz
  2002-07-18  9:50 ` Ben
  1 sibling, 0 replies; 29+ messages in thread
From: Scott Schwartz @ 2002-07-16 15:19 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
  2002-07-16 15:35 rog
@ 2002-07-16 14:42 ` Sam
  2002-07-16 15:39 ` Scott Schwartz
  1 sibling, 0 replies; 29+ messages in thread
From: Sam @ 2002-07-16 14:42 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
@ 2002-07-16 13:34 rog
  2002-07-16 15:19 ` Scott Schwartz
  2002-07-18  9:50 ` Ben
  0 siblings, 2 replies; 29+ messages in thread
From: rog @ 2002-07-16 13:34 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
  2002-07-15 16:45 rog
                   ` (2 preceding siblings ...)
  2002-07-15 19:21 ` Scott Schwartz
@ 2002-07-16 12:26 ` Martin C.Atkins
  3 siblings, 0 replies; 29+ messages in thread
From: Martin C.Atkins @ 2002-07-16 12:26 UTC (permalink / raw)
  To: 9fans

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.


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
@ 2002-07-16  7:39 Fco.J.Ballesteros
  0 siblings, 0 replies; 29+ messages in thread
From: Fco.J.Ballesteros @ 2002-07-16  7:39 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
  2002-07-15 16:45 rog
  2002-07-15 16:02 ` Sam
  2002-07-15 16:52 ` Lucio De Re
@ 2002-07-15 19:21 ` Scott Schwartz
  2002-07-16 12:26 ` Martin C.Atkins
  3 siblings, 0 replies; 29+ messages in thread
From: Scott Schwartz @ 2002-07-15 19:21 UTC (permalink / raw)
  To: 9fans

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!



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
  2002-07-15 16:45 rog
  2002-07-15 16:02 ` Sam
@ 2002-07-15 16:52 ` Lucio De Re
  2002-07-15 19:21 ` Scott Schwartz
  2002-07-16 12:26 ` Martin C.Atkins
  3 siblings, 0 replies; 29+ messages in thread
From: Lucio De Re @ 2002-07-15 16:52 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
@ 2002-07-15 16:45 rog
  2002-07-15 16:02 ` Sam
                   ` (3 more replies)
  0 siblings, 4 replies; 29+ messages in thread
From: rog @ 2002-07-15 16:45 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
@ 2002-07-15 16:33 okamoto
  0 siblings, 0 replies; 29+ messages in thread
From: okamoto @ 2002-07-15 16:33 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
  2002-07-15 16:45 rog
@ 2002-07-15 16:02 ` Sam
  2002-07-15 16:52 ` Lucio De Re
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 29+ messages in thread
From: Sam @ 2002-07-15 16:02 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
  2002-07-12 10:20 Fco.J.Ballesteros
@ 2002-07-15  9:30 ` Ben
  0 siblings, 0 replies; 29+ messages in thread
From: Ben @ 2002-07-15  9:30 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
@ 2002-07-12 16:16 anothy
  0 siblings, 0 replies; 29+ messages in thread
From: anothy @ 2002-07-12 16:16 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
@ 2002-07-12 10:44 okamoto
  0 siblings, 0 replies; 29+ messages in thread
From: okamoto @ 2002-07-12 10:44 UTC (permalink / raw)
  To: 9fans

>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



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
@ 2002-07-12 10:37 Fco.J.Ballesteros
  0 siblings, 0 replies; 29+ messages in thread
From: Fco.J.Ballesteros @ 2002-07-12 10:37 UTC (permalink / raw)
  To: 9fans

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.


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
@ 2002-07-12 10:32 okamoto
  0 siblings, 0 replies; 29+ messages in thread
From: okamoto @ 2002-07-12 10:32 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
@ 2002-07-12 10:20 Fco.J.Ballesteros
  2002-07-15  9:30 ` Ben
  0 siblings, 1 reply; 29+ messages in thread
From: Fco.J.Ballesteros @ 2002-07-12 10:20 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
@ 2002-07-12 10:15 okamoto
  0 siblings, 0 replies; 29+ messages in thread
From: okamoto @ 2002-07-12 10:15 UTC (permalink / raw)
  To: 9fans

>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



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
@ 2002-07-12  7:40 Fco.J.Ballesteros
  0 siblings, 0 replies; 29+ messages in thread
From: Fco.J.Ballesteros @ 2002-07-12  7:40 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
@ 2002-07-12  2:47 okamoto
  0 siblings, 0 replies; 29+ messages in thread
From: okamoto @ 2002-07-12  2:47 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [9fans] cdrom floppy tape etc, media mount point
@ 2002-07-12  2:17 anothy
  0 siblings, 0 replies; 29+ messages in thread
From: anothy @ 2002-07-12  2:17 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2002-07-30 11:45 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-12  2:07 [9fans] cdrom floppy tape etc, media mount point okamoto
2002-07-12  9:03 ` Don
2002-07-12  2:17 anothy
2002-07-12  2:47 okamoto
2002-07-12  7:40 Fco.J.Ballesteros
2002-07-12 10:15 okamoto
2002-07-12 10:20 Fco.J.Ballesteros
2002-07-15  9:30 ` Ben
2002-07-12 10:32 okamoto
2002-07-12 10:37 Fco.J.Ballesteros
2002-07-12 10:44 okamoto
2002-07-12 16:16 anothy
2002-07-15 16:33 okamoto
2002-07-15 16:45 rog
2002-07-15 16:02 ` Sam
2002-07-15 16:52 ` Lucio De Re
2002-07-15 19:21 ` Scott Schwartz
2002-07-16 12:26 ` Martin C.Atkins
2002-07-16  7:39 Fco.J.Ballesteros
2002-07-16 13:34 rog
2002-07-16 15:19 ` Scott Schwartz
2002-07-18  9:50 ` Ben
2002-07-18 16:06   ` Jack Johnson
2002-07-16 15:35 rog
2002-07-16 14:42 ` Sam
2002-07-16 15:39 ` Scott Schwartz
2002-07-16 16:09 rog
2002-07-18 11:19 rog
2002-07-30 11:45 Russ Cox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).