From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Mon, 20 Jan 2014 11:37:07 +0000 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=e89a8f646f8fbecdc504f0654fc3 Subject: Re: [9fans] Duplicate fids on 9p server Topicbox-Message-UUID: b3fe78b2-ead8-11e9-9d60-3106f5b1d025 --e89a8f646f8fbecdc504f0654fc3 Content-Type: text/plain; charset=UTF-8 On 20 January 2014 06:49, Amol Dixit wrote: > I see intro(5): "All requests on a connection share the same fid space" If several clients share one connection, as intro(5) says: "the agent managing the sharing must arrange that no two clients choose the same fid". That happens for instance with many cpu server processes sharing one 9p connection to the file server. That won't apply in your case, unless 9pfuse doesn't distinguish the different connections at the server. It's worth (re)reading the description of the protocol in section 5 of the manual to have a good grasp of the details, even when they are encapsulated by a library such as lib9p. "Basically the server should create new internal fids with ClientID+FID to point to the *same* file ...". You don't see that in (say) ramfs, because it has a single connection (the /srv file), and the kernel correctly manages the fid space for all client processes. Most 9p services are implemented that way. The few existing servers that manage distinct connections (eg, network connections), have per-connection state, and put the fid -> file map in that state. (There isn't any need to have an extra level of "internal fids", just keep a separate map per connection.) In fossil, for instance: struct Con { ... Fid* fidhash[NFidHash]; /* per-connection Fid map */ struct Fid { ... u32int fidno; /* actual 32-bit fid number chosen by client */ Con* con; /* the Fid belongs to one connection */ File* file; /* the Fid points to a File */ --e89a8f646f8fbecdc504f0654fc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 20 January 2014 06:49, Amol Dixit <amold@vmware.com> wrote= :
I

see intro(5): "All requests on a connection sh= are the same fid space"

If several clients share one connection, as intro(5)= says:
"the agent managing the sharing must arrang= e that no two clients choose the same fid".
That happens for instance with many cpu server processes sharing one = 9p connection to the file server.
That won't apply in your case, unless 9pfuse= doesn't distinguish the different connections at the server.

It's worth = (re)reading the description of the protocol in section 5 of the manual to h= ave a good grasp of
the details, even when they are encapsulated by = a library such as lib9p.

"Basically the server should create new internal = fids with ClientID+FID to point to the *same* file=C2=A0 ..."= .

You don't see that in (say) ramfs, because it has a si= ngle connection (the /srv file), and the kernel correctly manages
the fid space for all client processes. Most 9p services are implemented th= at way.

The few existing servers that manage distinct connections (eg, netwo= rk connections),
have per-connection state, and put the fid ->= file map in that state. (There isn't any need
to have an extra level of "internal fids", just keep a se= parate map per connection.)
In fossil, for instance:
struct Con {
=C2= =A0 =C2=A0 ...
Fid* fidhash[NFidHash]= ; =C2=A0 /* per-connection Fid map */

struct F= id {
=C2=A0 =C2=A0 ...
<= div class=3D"gmail_extra">
u32int fidno; =C2=A0 =C2=A0 =C2=A0/* actual 32-bit fid number chosen by= client */
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Con* con; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/* the Fid belongs to one connection */
File* file; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 /* the Fid points to a File */

 --e89a8f646f8fbecdc504f0654fc3--