[pnfs] Server sessions slot table patches

[William A. (Andy) Adamson]

On 4/4/07, Benny Halevy <bhalevy at panasas.com > wrote:
>
> My question is why are we hashing sessionid at all?
> Since the session_is is generated and returned by the server
> why not just use it as a handle to a server managed sessions table?


this is no different than the hash table of session_ids in the patch i
presented, when there are no collisions - except for the # of instructions
to calculate the hash index.

for example:
> struct nfsd_session_id {
>         u32 si_handle;  /* index to the server sessions table */
>         struct nfstime4 si_crtime; /* session create time */
> };


with this session_id, we will have to look up the clientid. we need to look
at the lease time on each OP_SEQUENCE. the clientid lookup is a hash table
(!).

 This will allow the nfsd to detect stale sessions after a server reboot,
>
or after purging inactive sessions, or after reusing a slot in the
> sessions table if the client closes the session cleanly;


no. there is no NFS4ERR_STALE_SESSION - a session is stale only if the
clientid is stale. the session create time cannot be used to determine stale
client state.

from minorversion1-10

   If sr_status_flags from the metadata server has
   SEQ4_STATUS_RESTART_RECLAIM_NEEDED set (or SEQUENCE returns
   NFS4ERR_STATE_CLIENTID, or SEQUENCE returns NFS4ERR_BAD_SESSION and
   CREATE_SESSION returns NFS4ERR_STATE_CLIENTID) then the metadata
   server has restarted, and the client must recovery using the methods
   described in Section 12.7.4.

The session table itself can be either bound in size, or grow by
> reallocation
> in case it overflows, or be the spine of a hash table, using the the
> si_crtime
> as a uniquifier.  Again, the spine can be reallocated in case the buckets
> fill up.


this is no different than the the hash table of session_id's with collisions
in the patch i presented.

the way i have it coded, the session_id contains the clientid, and can
therefore be used with no lookup to determine STALE_CLIENTID. the session_id
hash table can dynamically resized (to the next prime) - there are easy ways
to calculate the average depth of the table to trigger resize.

Benny
>
> Iyer, Rahul wrote:
> > Hi Andy,
> > The exchange_id patches look ok. As for the slot table patches, I had a
> > couple of comments:
> >
> > How fast is crc32c? Since it's a crypto digest/CRC calculator (I don't
> > know what it is), is it slow? We don't wasn't this being a bottleneck.
> > We need a reasonable hash with a decent spread, not necessarily a secure
> > one.
> >
> > Also, I'd suggest making the has table size prime... It helps the spread
>
> > with the modulo.
> >
> > In patch 0007 of the slot table, in nfsd4_sequence, the KERN_EMERG could
> > be KERN_ERROR or KERN_NOTICE (I know I'm responsible for the EMERG ;) )
> >
> > Regards
> > Rahul
> >
> >
> >> -----Original Message-----
> >> From: William A. (Andy) Adamson [mailto: andros at citi.umich.edu]
> >> Sent: Tuesday, April 03, 2007 6:43 AM
> >> To: pnfs at linux-nfs.org
> >> Subject: [pnfs] Server sessions slot table patches
> >>
> >> hi
> >>
> >> here are 9 patches that implement the server slot table
> >> management. there is not DRC yet, but this code has been
> >> developed with the DRC in mind. This code almost passes the
> >> connectathon tests on the 4.1-sessions branch with the client
> >> patches i just sent out.
> >>
> >> it fails the general connectathon tests with an
> >> NFS4ERR_SEQ_MISORDERED. i note that the client mostly uses
> >> slot 0, and occasionally uses slot 1. the slot 1 sequence is
> >> out of order - i don't know if it is the client or server.
> >>
> >> please review the patches...
> >>
> >> thanks
> >>
> >> -->Andy
> >>
> >>
> > _______________________________________________
> > pNFS mailing list
> > pNFS at linux-nfs.org
> > http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux-nfs.org/pipermail/pnfs/attachments/20070404/e8d6bd8b/attachment.htm