Subject: [nfsv4] Notes from part 4 of the sessions review panel

From: Trond Myklebust <[email-masked]>
Date: Mon, 21 May 2007 17:39:53 -0400

Fred Isaman          (CITI)
Spencer Shepler      (Sun)    Moderator -
Mike Eisler          (NetApp) Author -
Trond Myklebust      (NetApp) Scribe -
Dave Noveck          (NetApp) -
John Scott           (NetApp) -
Peter Shah           (NetApp) -
Tom Talpey           (NetApp) Reader -
Benny Halevy         (Panasas) -
Rick Macklem         (Guelph) -

-------------------------------------------------------------

-------------
Talpey 23821	The server MUST cache the reply is only true if
		permanent caching semantics is enabled
Noveck		Not true, it must always cache. The only issue
		is
-------------
Talpey		Need a description of what to put into sa_slotid after
		23823.
-------------
Macklem 23829	Does cache persistence affect the issue of lock state being
		lost?
Noveck		Need to clarify what happens if you retain lock state across
		the reboot.
-------------
Isaman 23845	Is this flag client-specific or session-specific?
Noveck		This is all client-specific. Noveck to check if there are
		any session-specific cases that need to be handled.
Eisler		There is the issue of recalling slots, which is session
		specific...
Macklem		PATH_DOWN is really "BACKCHANNEL_DOWN".
-------------
Isaman 23860	Same question
Eisler		Definitely client-specific
Isaman		Are GSS contexts per-session or per-client?
Eisler		They are per-session.
Noveck		Can you have different expiration times etc per session?
		What are consequences? Should the bit be set?
Eisler		As long as you have one active backchannel, you're OK.
Noveck		Need to clarify how people are going to use this...
Eisler		The bit should be used to indicate that the last GSS
		context is about to expire.
		Consensus...
------------
Myklebust 23893	Don't use 'locks'.
Noveck		Really talking about delegations and layouts, which are not
		locks.
		Noveck to look at the text for FREE_BADLOCK to ensure that
		it is appropriate for delegations and layouts
------------
Isaman 23917	Please fix grammar.
Eisler		When set indicates that due a to server restart or reboot
		the client must be prepared to reclaim state.
		Consensus...
------------
Talpey 23927	Please separate this paragraph into 3 bulletized paragraphs
		describing the 3 cases.
		Consensus...
-----------
Talpey 23942	I'd like to see a MUST here.
		Consensus...
-----------
Noveck 23962	What does "the server MUST also persist the client ID,"
Eisler		The lock state may be lost, but you can reuse the client ID
		SSV, the Session ID and the session state.
Noveck		Make sure that this is listed somewhere.
Macklem		How does the client know that it should go into reclaim mode?
Eisler		The status flag will be set.
Noveck		Is this covered by SEQ4_STATUS_EXPIRED_ALL_STATE_REVOKED?
		No. Server will return SEQ4_STATUS_RESTART_RECLAIM_NEEDED
Myklebust	What error will be returned for the lock request?
Noveck		You will be in GRACE period, so probably return
		error for that... ...or BAD_STATEID for something like
		OPEN_DOWNGRADE.
Eisler		What about a new OPEN? That should succeed except for the
		GRACE period.
		Need text to clarify that the request may succeed, but you
		should still test the status bits.

		Client could be confused by OPEN upgrade that leaves the
		status of whether the file is open for READ, WRITE or
		READ/wITE uncertain...

		Needs further discussion...
-----------
Scott 25350	Could this callback refer to multiple session ids?
Noveck+Eisler	Yes
Scott		What does that mean?
Eisler		Meant to deal with the case of delegations etc when the
		recall potentially happens over a different session.
		i.e. It deals with the known v4.0 race...
-----------
Noveck 25407	What happens if the session goes away?
Talpey		If the session no longer exists, then there is no race. The
		client will know about the object that is about to be recalled.
		Add text to note this? Also note that the client should check.
Eisler		Reference to Section 2.10.4.3 is supposed to deal with this.
		Add discussion there...
-----------
Myklebust	What about if the server screws up the slotid? Who is
		responsible for recovering and how?
Talpey		The only recourse is for the client to tear down the session
		and restart.
Eisler		Add a status error "my mind is going"?
Shepler		Server could send a CB_PATHDOWN error on the next SEQUENCE?
Eisler		Not really, 'cos the session is bad here. You don't want to
		just add a new callback path.
		Consensus is to add a 'losing my mind' flag.
------------
Talpey 25414	See discussion about the same flags on SEQUENCEID operation.
		Same things apply here.
-----------
Talpey 25436	Add normative language
------------
Talpey 25439	Why would you want more than 1 slot?
Eisler		Could lead to bursty recalls if the server has too few slots.
Talpey		Do we need implementation advice here?
Eisler		Perhaps point out that a server might sanction clients that
		hand out too few slots on high latency links by limiting the
		number of delegations it hands out.
------------
Eisler 25282	Author notes that the target doesn't match the synopsis.
------------
Talpey 25327	Add a section about what sanctions the server might take
		if the client doesn't respond to the request.
------------

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4