Subject: [nfsv4] deviceid4 => major/minor

From: Spencer Shepler <[email-masked]>
Date: Thu, 08 Nov 2007 01:24:58 -0600

As discussed recently, there is a desire to allow for the
separation of the deviceid stateid space such that a logical
set of deviceids may be grouped and then managed or recalled
without disruption to other groupings.

The most straightforward modification, as suggested, is to
change the current deviceid definition from:
	typedef uint64_t deviceid4;

to:

	struct deviceid4 {
		uint64_t	did_major;
		uint64_t	did_minor;
	};

Along with this change the deviceid stateid space would
change such that there is a unique deviceid stateid
associated with each deviceid4.did_major used by the server.

As a quick reminder:

Deviceid stateids represent a delegation of the deviceid
mapping to the client.

Upon receipt of results from GETDEVICEINFO/GETDEVICELIST, the
client holds a deviceid delegation for the returned mapping(s).

When the mapping is no longer needed or is recalled by the server,
the client will use DELEGRETURN to signify completion.  Note that
this requires a valid filehandle to be returned/updated by
GETDEVICELIST/GETDEVICELIST.

The server may recall the deviceid mappings with the CB_RECALL
operation.

If supported and the client desires, interest in notifications
of changes in the deviceid mappings may be provided with the
CB_NOTIFY operation.

FREE_STATEID and TEST_STATEID may be used as with other
stateid types.

--

If there aren't any obvious flaws with this approach,
I will make the changes to be included in the next update
to the draft.

Spencer

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

---

From: Garth Goodson <[email-masked]>
Date: Thu, 08 Nov 2007 13:50:43 -0800

> associated with each deviceid4.did_major used by the server.

How many deviceid stateid are returned by GETDEVICELIST?

If just one deviceid stateid per result (as it is now) then I guess all 
have to have the same did_major.  In this case, how does the client then 
do a GETDEVICELIST for devices with other did_majors (assuming they can 
exist)?

-Garth

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 08 Nov 2007 19:07:15 -0600

On Nov 8, 2007, at 3:50 PM, Garth Goodson wrote:

> If just one deviceid stateid per result (as it is now) then I guess  
> all have to have the same did_major.  In this case, how does the  
> client then do a GETDEVICELIST for devices with other did_majors  
> (assuming they can exist)?

Oversight; my apologies.

The stateid would move into the devlist_item4 struct
and the changes would look like this:

----

struct devlist_item4 {
         deviceid4                 dli_id;
	stateid4		  dli_stateid;
         device_addr4              dli_device_addr;
};

struct GETDEVICELIST4resok {
         nfs_cookie4             gdlr_cookie;
         verifier4               gdlr_cookieverf;
         device_notification_mask4 gdlr_notification;
         devlist_item4           gdlr_devinfo_list<>;
         bool                    gdlr_eof;
};

---

From: Benny Halevy <[email-masked]>
Date: Mon, 12 Nov 2007 14:10:02 +0200

> and the changes would look like this:

OK. I think that we just need to provide guidance on how to
use dli_stateid when there are multiple devlist items on the list
for the same did_major.  I presume they all need to have the same
stateid.other, but should they all use the same dli_stateid.seqid
or should it be incremented for every entry?  I think the latter
the method is safer and that the client should remember the last
dli_stateid returned for this did_major.

Also, there's no way to list the devices just for a specified
did_major (as was in my proposal).  Is this intentional?

Benny

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 12 Nov 2007 11:07:02 -0500

> I think the latter the method is safer and that the client 
> should remember the last dli_stateid returned for this did_major.

If there is a possiblity that he will be doing requests in 
parallel for a given major id, he needs to save the highest one
(mod wraparound issues) just as for parallel opens.  He can't 
assume that that last one he gets is the last one the server
processed.

He may be able not to record this at all and use seqid = 0 and 
let the server deal with it.

-----Original Message-----
From: Benny Halevy [mailto:[email-masked]] 
Sent: Monday, November 12, 2007 7:10 AM
To: Spencer Shepler
Cc: Goodson, Garth; NFSv4
Subject: Re: [nfsv4] deviceid4 => major/minor

On Nov. 09, 2007, 3:07 +0200, Spencer Shepler <[email-masked]>
wrote:
>>> As discussed recently, there is a desire to allow for the separation

>>> of the deviceid stateid space such that a logical set of deviceids 
>>> may be grouped and then managed or recalled without disruption to 
>>> other groupings.
>>> The most straightforward modification, as suggested, is to change 
>>> the current deviceid definition from:
>>> Along with this change the deviceid stateid space would change such 
>>> that there is a unique deviceid stateid associated with each 
>>> deviceid4.did_major used by the server.
> The stateid would move into the devlist_item4 struct and the changes 
> would look like this:

OK. I think that we just need to provide guidance on how to use
dli_stateid when there are multiple devlist items on the list for the
same did_major.  I presume they all need to have the same stateid.other,
but should they all use the same dli_stateid.seqid or should it be
incremented for every entry?  I think the latter the method is safer and
that the client should remember the last dli_stateid returned for this
did_major.

Also, there's no way to list the devices just for a specified did_major
(as was in my proposal).  Is this intentional?

Benny