Garth Goodson <Garth.Goodson netapp.com> wrote on
06/27/2007 01:41:34 PM:
>
>
> Marc Eshel wrote:
> > Mike Eisler <email2mre-ietfyahoo.com> wrote on 06/27/2007 11:08:48
AM:
> >
> >> --- Marc Eshel <eshelalmaden.ibm.com> wrote:
> >>
> >>>> A similar argument can be made for
delegations, but we've
> >>>> managed without CB_RECALL by FSID or
by client ID. My
> >>>> recollection during the pNFS
inspections is that client
> >>> implementors
> >>>> found the recall by FSID burdensome
because it required them
> >>>> to maintain a data structure that a
server might never use.
> >>>> [...] The server can change the layout
as nodes leave or
> >>> join
> >>> the cluster which is a frequent enough
event in a large cluster and
> >>> requires an efficient way to recall
layouts per FSID. The layout can
> >>> change without impacting delegations or
any other state because
there
> >>> was
> >>> a change in the list of Data Servers.
> >> If node leaves the cluster that's going affect
multiple
> >> file systems (FSIDs). Indeed, in some
deployments, it
> >> will affect all FSIDs. Moreoever, deleting a
node shouldn't
> >> necessarily affect all files of a particular
FSID.
> >
> > A better example would be when you need to umount
or disable a
particular
> > file system for some internal problems.
> >
> >> So I see the motivation, but I don't see
recall by FSID as the
> >> best solution. Recall by device ID seems
closer to the solution.
> >>
> >> Benny suggests that the device ID be made into
64 bits. What if
> >> it were optionally partitioned somehow, such
that the upper bits were
> >> for a "major" device ID, and the
lower bits for the "minor" device
> >> ID. When a client gets a layout, the device ID
is encoded
> >> to indicate whether the device ID is
partitioned or not.
> >> If the device ID is partitioned, then this is
a clue to the
> >> client that when a RECALL_DEVICEID
CB_LAYOUTRECALL occurs,
> >> the client must be prepared to search by the
major deviceID
> >> if the recall specifies so.
> >>
> >> Encoding the device ID:
> >>
> >> Alternative 1: split the the 64 bit device ID
into two
> >> 32 bit fields, di_major and di_minor. If the
highest order of
> >> di_major is set to one, then this means the
remaining 63 bits are
> >> considered flat, otherwise they are
partitioned. If partitioned,
> >> a di_minor == 0 means di_major refers to all
device IDs with the
> >> same
> >>
> >> Alternative 2: Allow for major and minor
device IDs of different
> >> sizes, and have single uint64_t represent the
> >> device ID. As with alternative 1, if the
higher order bit is 1,
> >> the remaining 63 bits are a flat device ID.
Otherwise, the
> >> next 7 bit represent how many bits of the
remain 56 are
> >> for the major device ID, with the rest then
being for the minor
> >> device ID. As with alternative 1, a minor
devide ID of zero means
> >> the major device ID refers to all devices with
the same major device
> >> ID.
> >>
> >
> > So are you saying that we will have a call that or
a given device id
> > recall all layouts that included this device id ?
That should work.
> >
>
> Isn't the problem that you still have to return them
(the layouts) one
> by one since they are now represented by stateids? Or
would you propose
> that the server keep a mapping that would allow a
return of this type
> with no stateid.
Yes that would be nice, I assume that the server will have
to keep layout
list for a given client and the layout includes the device
id so it will
be possible to support in one call.
Marc.
>
> -Garth
_______________________________________________
nfsv4 mailing list
nfsv4ietf.org
https://
www1.ietf.org/mailman/listinfo/nfsv4
|