[pnfs] Where should nfs4_session be referenced?

[William A. (Andy) Adamson]

On Jan 10, 2008 5:31 PM, Iyer, Rahul <Rahul.Iyer at netapp.com> wrote:

>
>
> > -----Original Message-----
> > From: Labiaga, Ricardo
> > Sent: Thursday, January 10, 2008 2:08 PM
> > To: pnfs at linux-nfs.org
> > Subject: [pnfs] Where should nfs4_session be referenced?
> >
> > Rahul, Andy,
> >
> > In the sessions rewrite (2.6.24) we moved the nfs4_session to
> > be referenced from the nfs_server structure.  One of the
> > reasons was that it would theoretically allow us to have
> > different session semantics when mounting different types of
> > filesystems from the same physical server.
> > For example, if you were to mount a tape library, you could
> > specify a set of session parameters that could be different
> > from a disk based filesystem.
> >
> > After a conversation with Trond and Tom Talpey, it's not
> > clear that it makes sense to have different sessions for
> > different mounts sharing the same transport.  Does it make
> > more sense to have different sessions each with its own
> > transport if needed?  Today in Benny's tree we may have
> > multiple nfs_server structures each with its own
> > nfs4_session, but they may be sharing the same rpc_xprt.
>
> Well, one thing I can definitely think of is a hard partitioning of the
> slots. For example, an rpc_xprt has a user defined/default number of rpc
> slots. If the sessions wanted to partition these slots amongst
> themselves they can do so by setting the number of slots less than the
> number of slots available in the rpc_xprt. This is a hard partition such
> that a burst in the number of rpcs  on one session leaves the other
> unaffected. I like this particular quality.
>
> On the other hand, if they don't care, they can set their number of
> session slots to the total number of rpc slots and so would get no
> isolation guarantee.
>
> The problem however, is how this can be achieved. Currently, there is no
> way to specify session slots. The only way is to set the rpc slots and
> the session slots will follow. Maybe via a mount option for the session
> slots?
>
> > This complicates the backchannel implementation and the pNFS
> > implementation.  Andy had to add an nfs4_session pointer to
> > the nfs_client anyway since a DS doesn't have an nfs_server structure.
> >
>
> 2 questions:
> 1. In what way does it complicate the backchannel implementation (I can
> see some issues, but I was wondering what you were hinting at).
> 2. Why did Andy need it in the nfs_client? Or more fundamentally, why
> does a DS have an nfs_client? Isn't that a *very* big hammer struct to
> store what would essentially be a clientid and a session pointer? IMHO,
> majority of the fields will be absolutely unused!


it is true that the nfs_client struct is a big hammer for a DS which will
have no state, no lease, etc. this is noted in the comments when i
introduced sessions to the DS. the plan is to extract the session managenent
fields from struct nfs_client (and struct nfs_server) into a new structure
to use for all session management. i did not do this on the first pass as
the struct nfs_client is the 'coin of the realm' - passed to most of the
functions used for DS setup and communications.

as we re-think how the sessions are associated with mounts, perhaps it is
time to split struct nfs_client into two pieces: what is needed for a DS and
what else is needed for MDS/NFSv4.1 mounts.

-->Andy


>
> Thanks
> Rahul
>
>
> > Does anyone see a problem if we move the nfs4_session
> > reference back to the nfs_client instead of the nfs_server?
> > This will simplify the pNFS implementation so that it handles
> > the session the same way as non-pNFS and will simplify the
> > backchannel as well.
> >
> > Thoughts?
> >
> > - ricardo
> > _______________________________________________
> > pNFS mailing list
> > pNFS at linux-nfs.org
> > http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs
> >
> _______________________________________________
> 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/20080111/1a27b51f/attachment.htm