[9fans] QIDs

[9fans] QIDs

[Steve Simon]

beginners question:

Internally in the kernel it matches full QIDs dosn't it?

That is it doesn't compare only the qid.path, so in my
syntetic file server I can differentiate between files
by using a unique-to-me qid.type and then using qid.path
to hold the index of my files in a table?

Seccondly, if I am going to use other bits from qid.type
is there any reccomded practice as to which ones to use
(I assume the lower ones as the upper ones are defined),
however I do rembember somthing about an agregating server
shifting the bits of clients down so they can be combined
uniquely....

Thanks,

-Steve

Re: [9fans] QIDs

[Charles Forsyth]

> That is it doesn't compare only the qid.path, so in my
> syntetic file server I can differentiate between files
> by using a unique-to-me qid.type and then using qid.path
> to hold the index of my files in a table?

qid.type is defined to be the top 8 bits of the mode
so unless you meant QTDIR vs QTFILE, the value can't
sensibly be used by the server.

in simple cases, the path is just an index, selecting file-specific (meta)data,
which could include the server-specific file type.

in multiplexors, commonly a few bits of the path give a file type (eg, ctl, data etc)
and (many) more bits give the conversation number.

>however I do rembember somthing about an agregating server
>shifting the bits of clients down so they can be combined
>uniquely....

i think the suggestion was that in the path (not the type), the server
should try to stick to the low-order 48 bits, leaving the high-order bits
available so that exportfs and others could more easily generate new paths
that were (quite likely) to be unique immediately (but they'd still have to
cope, if not)

Re: [9fans] qids

[rog]

> Servers of original files are encouraged to use only the low 48 bits
> of the qid.path to permit encapsulating servers to use the top 16 bits
> to generate uniqueness.

what about those that encapsulate the encapsulators?

i don't see how this helps much, given that you can't rely
on it. i suppose it reduces the likelyhood that an exportfs-like
service will have to rewrite a file's qid when it's walked to,
and more so if the encapsulating service chooses a random
starting point for those top 16 bits... is that the point?

  rog.

[9fans] qids

[vic]

I am writing a file server to be overlayed on a portion
of an existing name space.  It presents the original
name space, plus some new files.

I'm trying to decide how to manage the qids.  The issue
is choosing qids for the new files without colliding
with qids of the old ones.

The best related example I've seen is the qid hash
table in exportfs.  Is there a better one?

Vic

Re: [9fans] qids

[rob pike, esq.]

> I am writing a file server to be overlayed on a portion
> of an existing name space.  It presents the original
> name space, plus some new files.
> 
> I'm trying to decide how to manage the qids.  The issue
> is choosing qids for the new files without colliding
> with qids of the old ones.

If your server is a separate mount point that doesn't
itself serve the underlying files, don't worry about it;
the server is part of the uniqueness criteria for the files.

> The best related example I've seen is the qid hash
> table in exportfs.  Is there a better one?

If you are instead serving leftovers like exportfs, then
you'll need to something analogous.  Servers of original
files are encouraged to use only the low 48 bits of the
qid.path to permit encapsulating servers to use the top
16 bits to generate uniqueness.  The code in exportfs
may be a good example, but last I looked it was a bit
obscure.

-rob

Re: [9fans] qids

[Axel Belinfante]

Thanks for this remark. I have been wondering about this too.

I still hope to someday reimplement (or have students reimplement)
one of our tools on plan 9, and then `heavily' use overlaying.
The idea would be to have a chain (pipeline?) of tools,
where each of them extends (or modifies?) the file hierarchy
it gets from its predecessor in the chain.
So far, I have mainly been thinking about file servers that
extend the set of files they get, like e.g. starting with
fileserver A, and then have fileserver B which serves the 
iles of A, together with a few files that B adds itself
using information taken from files of A.
Then C would take its files from B, etc.
There would probably be a different kind of fileserver D
that gives a whole new view of the stuff from C,
instead of just adding files to it.

The advantage I would have wrt qids is that (assuming I
`control' all tools in the chain) I would be able to devise
my own conventions to guarantee uniqueness.

It occured to me that this approach looks a bit like passing
(attributed?) (abstract syntax) trees around between
components in a tool chain. The extending file server
then essentially just adds additional attributes to the tree.

I don't expect this approach to be the most efficient one
w.r.t. burning cpu cycles, but it should result in a pretty
flexible tool set, where you `build' a particular tool (instance)
by combining the `right' elements in the tool chain.
To get a slightly different tool, you just replace a component
by one that implements a slightly different algorithm.
Also, it has the (educational) advantage that it makes the
intermediate (tree) data structures visible using ordinary
tools (just look at the file hierarchy and the files served).

Someday I'll really find some time to work on this, someday...

Axel.


> Servers of original
> files are encouraged to use only the low 48 bits of the
> qid.path to permit encapsulating servers to use the top
> 16 bits to generate uniqueness.  The code in exportfs
> may be a good example, but last I looked it was a bit
> obscure.