* [9fans] simple questions on bind semantics
@ 2004-09-28 0:46 Roman Shaposhnick
2004-09-28 0:51 ` Rob Pike
0 siblings, 1 reply; 9+ messages in thread
From: Roman Shaposhnick @ 2004-09-28 0:46 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
I have a deja vu feeling that this might have been asked here before.
But since the mighty google disagrees here it goes: why does bind
have a restriction that old has be existent ? Basically why can't
I do:
$ bind /some-file /new-name-for-some-file ?
where there's no /new-name-for-some-file before the call ?
Thanks,
Roman.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] simple questions on bind semantics
2004-09-28 0:46 [9fans] simple questions on bind semantics Roman Shaposhnick
@ 2004-09-28 0:51 ` Rob Pike
2004-09-28 13:57 ` C H Forsyth
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Rob Pike @ 2004-09-28 0:51 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
Because bind and mount are implemented by a simple substitution.
When a walk hits a file that has been bound to, the fid is dropped
and then replaced by a clone of the fid of the result of the bind.
To have a fid, one needs a file, hence the fid must exist.
There's nothing stopping a service from creating bind destinations
on demand, and I think this has even been done in a special
device(memory is vague), but fundamentally, bind needs a file to
bind to.
-rob
On Mon, 27 Sep 2004 17:46:57 -0700, Roman Shaposhnick <rvs@sun.com> wrote:
> I have a deja vu feeling that this might have been asked here before.
> But since the mighty google disagrees here it goes: why does bind
> have a restriction that old has be existent ? Basically why can't
> I do:
>
> $ bind /some-file /new-name-for-some-file ?
>
> where there's no /new-name-for-some-file before the call ?
>
> Thanks,
> Roman.
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] simple questions on bind semantics
2004-09-28 0:51 ` Rob Pike
@ 2004-09-28 13:57 ` C H Forsyth
2004-09-29 1:08 ` Roman Shaposhnick
2004-09-29 3:13 ` Roman Shaposhnick
2004-09-29 17:06 ` Richard Miller
2 siblings, 1 reply; 9+ messages in thread
From: C H Forsyth @ 2004-09-28 13:57 UTC (permalink / raw)
To: 9fans
mntgen(4), for instance, generates names on demand.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] simple questions on bind semantics
2004-09-28 13:57 ` C H Forsyth
@ 2004-09-29 1:08 ` Roman Shaposhnick
2004-09-29 1:23 ` andrey mirtchovski
0 siblings, 1 reply; 9+ messages in thread
From: Roman Shaposhnick @ 2004-09-29 1:08 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Tue, Sep 28, 2004 at 02:57:42PM +0100, C H Forsyth wrote:
> mntgen(4), for instance, generates names on demand.
mntgen seems new to me (I could bet it wasn't part of the
Plan 9 release 3, but may be I've just overlooked it)
Anyway, is this how one accomplishes what I was trying
to do (bind /existing-file /non-existing-file):
$ mntgen /
$ bind /existing-file /non-existing-file
The one thing that troubles me about this approach is that
all of a sudden any lookup in / starts succeeding.
Thanks,
Roman.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] simple questions on bind semantics
2004-09-29 1:08 ` Roman Shaposhnick
@ 2004-09-29 1:23 ` andrey mirtchovski
2004-09-29 8:37 ` Fco. J. Ballesteros
0 siblings, 1 reply; 9+ messages in thread
From: andrey mirtchovski @ 2004-09-29 1:23 UTC (permalink / raw)
To: 9fans
> mntgen seems new to me (I could bet it wasn't part of the
> Plan 9 release 3, but may be I've just overlooked it)
>
nemo wrote mntgen sometime around the initial 4e...
> Anyway, is this how one accomplishes what I was trying
> to do (bind /existing-file /non-existing-file):
whenever i run into that problem i use ramfs, or i bind /tmp if
i don't care that someone may see the changes to the file.
hth: andrey
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] simple questions on bind semantics
2004-09-28 0:51 ` Rob Pike
2004-09-28 13:57 ` C H Forsyth
@ 2004-09-29 3:13 ` Roman Shaposhnick
2004-09-29 17:06 ` Richard Miller
2 siblings, 0 replies; 9+ messages in thread
From: Roman Shaposhnick @ 2004-09-29 3:13 UTC (permalink / raw)
To: Rob Pike, Fans of the OS Plan 9 from Bell Labs
On Mon, Sep 27, 2004 at 05:51:54PM -0700, Rob Pike wrote:
> To have a fid, one needs a file, hence the fid must exist.
That's the part I'm curious about. Why is that ? For the
purposes of substituting you still have to maintain the
information that file X is a 'bind' destination for file Y.
Sure the lookup is much simpler when you really have Y and
Z being served somewhere, but wouldn't it be quite simple
to have a table (with a usual performance hit) that you consult
when the real walk fails ?
Or, to put differently, why mntgen is considered a better
(or cleaner) solution than what I've just described.
Thanks,
Roman.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] simple questions on bind semantics
2004-09-29 1:23 ` andrey mirtchovski
@ 2004-09-29 8:37 ` Fco. J. Ballesteros
0 siblings, 0 replies; 9+ messages in thread
From: Fco. J. Ballesteros @ 2004-09-29 8:37 UTC (permalink / raw)
To: 9fans
>> Anyway, is this how one accomplishes what I was trying
>> to do (bind /existing-file /non-existing-file):
In Plan B we used to have a prefix table (now it's gone).
There you could say something like
/a/path/I/just/invented -goes-to-> a-file-server
This has the net effect that you can invent paths.
It was not that useful. I mean, you can perfectly do without
inventing files. Sometimes I missed this to patch up CDs, but
that's a different issue.
hth
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] simple questions on bind semantics
2004-09-28 0:51 ` Rob Pike
2004-09-28 13:57 ` C H Forsyth
2004-09-29 3:13 ` Roman Shaposhnick
@ 2004-09-29 17:06 ` Richard Miller
2004-10-01 17:36 ` Roman Shaposhnick
2 siblings, 1 reply; 9+ messages in thread
From: Richard Miller @ 2004-09-29 17:06 UTC (permalink / raw)
To: 9fans
> There's nothing stopping a service from creating bind destinations
> on demand, and I think this has even been done in a special
> device
That's mntgen(4).
But if you want to create only one specific bind destination instead
of having them appear on demand, you can use stub(8).
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] simple questions on bind semantics
2004-09-29 17:06 ` Richard Miller
@ 2004-10-01 17:36 ` Roman Shaposhnick
0 siblings, 0 replies; 9+ messages in thread
From: Roman Shaposhnick @ 2004-10-01 17:36 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Wed, Sep 29, 2004 at 06:06:00PM +0100, Richard Miller wrote:
> > There's nothing stopping a service from creating bind destinations
> > on demand, and I think this has even been done in a special
> > device
>
> That's mntgen(4).
>
> But if you want to create only one specific bind destination instead
> of having them appear on demand, you can use stub(8).
Thanks. stub(8) looks pretty much like what I really need. However,
it got me thinking: what if I need more stubs than one -- for every
one of them there'll be a separate process serving one file, right ?
Even with COW paging this sort of looks like an overkill, wouldn't
it be possible to serve all "stubs" with one process, using the
third ("spec") option of mount as a distinguishing factor.
Thanks,
Roman.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2004-10-01 17:36 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-28 0:46 [9fans] simple questions on bind semantics Roman Shaposhnick
2004-09-28 0:51 ` Rob Pike
2004-09-28 13:57 ` C H Forsyth
2004-09-29 1:08 ` Roman Shaposhnick
2004-09-29 1:23 ` andrey mirtchovski
2004-09-29 8:37 ` Fco. J. Ballesteros
2004-09-29 3:13 ` Roman Shaposhnick
2004-09-29 17:06 ` Richard Miller
2004-10-01 17:36 ` Roman Shaposhnick
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).