If the client gets a COMPLEX device which is an array of
pnfs_deviceid4
than what is the id of the quasi-device?
It is the device id that was in the layout which you used to fetch the
device info, which in turn contains the array of pnfs_deviceid4's.
how do you distinguish between quasi-device and real device,
The device info for files is a discriminated union where there
are separate cases for SIMPLE and COMPLEX.
are they sharing the same name (id) space?
Yes. This is principally to avoid additional ops. By making these
things devices, we allow DEVINFO to be used and the discriminated
union supports multiple types of devices or device-like
aggregations. The big benefit is when many files make reference to
the same device
aggregations.
-----Original Message-----
From: Marc Eshel [mailto:eshel at almaden.ibm.com] Sent: Friday, July
07, 2006 4:54 PM
To: Noveck, Dave
Cc: Goodson, Garth; nfsv4 at ietf.org
Subject: RE: [nfsv4] pnfs: efficient file-layout striping proposal
Yes, we can continue to talk in Montreal but it would be useful to
clarify your proposal as much as possible before the meeting. [ more
text in-line ]
"Noveck, Dave" <Dave.Noveck at netapp.com> wrote on 07/07/2006 11:51:32
AM:
Marc Eshel:
Where does the client hang the shared parts of the layout? How
long should the client keep them around?
This is where storing this quasi-devices means the complexity
impact is about zero. You do exactly what you do with device
definitions.
You keep them is some sort of hash by low-order dev-id bits and you
LRU them.
How does the server know that the client still holds the shared
part?
He doesn't and he doesn't have to. This works exactly the same as
device definitions which are shared among layouts. The server
gives an id without knowing whether the client has or has not
fetched the definition corresponding to a given id. It is up to
the client to fetch it if it doesn't have it.
This make a little more sense, but I still don't see how you get this
new quasi-devices from to original proposal. Maybe you can explain
using
the new proposed struct
union nfsv4_file_layout_device4 switch (file_layout_device_type) {
case SIMPLE: <--- NEW
nfsv4_file_layout_simple_device4 dev; <--- NEW
case COMPLEX: <--- NEW
pnfs_deviceid4 dev_list<>; <--- NEW
default:
void;
};
If the client gets a COMPLEX device which is an array of pnfs_deviceid4
than what is the id of the quasi-device? how do you distinguish between
quasi-device and real device, are they sharing the same name (id)
space?
Just trying to understand better the proposal.
Marc.
_______________________________________________
nfsv4 mailing list
nfsv4 at ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4