[pnfs] 19 questions

[William A. (Andy) Adamson]

On Feb 6, 2008 1:26 PM, Dean Hildebrand <seattleplus at gmail.com> wrote:

>
> William A. (Andy) Adamson wrote:
> >
> >
> > On 2/4/08, *Dean Hildebrand* <seattleplus at gmail.com
> > <mailto:seattleplus at gmail.com>> wrote:
> >
> >     Some questions about draft 19 (not 19 questions):
> >
> >     1) On the server I need the superblock so I can call the
> getdeviceinfo
> >     export operation.
> >
> >
> > why? the deviceid space is global.
> Well, the devices and the device ids still come from the file system,
> and the only way I know how to talk to the file system is through the
> export ops, which requires a superblock.
>
> To make them globally unique, through coincidence or the fact that we
> are all very like minded people, we had already coded up the deviceid on
> the server as Benny suggested:
>
> struct pnfs_deviceid {
>        u64     ex_fsid;
>        __be64  devid;
> };
>
> One limitation here is that in include/linux/nfsd/nfsfh.h it defines the
> sizes for various types of fsids:
> static inline int key_len(int type)
> {
>        switch(type) {
>        case FSID_DEV:          return 8;
>        case FSID_NUM:          return 4;
>        case FSID_MAJOR_MINOR:  return 12;
>        case FSID_ENCODE_DEV:   return 8;
>        case FSID_UUID4_INUM:   return 8;
>        case FSID_UUID8:        return 8;
>        case FSID_UUID16:       return 16;
>        case FSID_UUID16_INUM:  return 24;
>        default: return 0;
>        }
> }
>
> So if we are limiting the fsid to be only 8 bytes, then there are
> several types of fsids we cannot support.  I'm wondering if this is a
> major problem for all OSs or just a hassle for all OSs.  There are
> workarounds I guess (replace fsid with a made up id in /etc/exports) but
> they seem like a hassle.  What do people think?


svc_export->ex_dentry->d_inode->i_sb gives you a super block for an export.

the server can remember which exports (only need one) are pNFS vi any pNFS
call (such as the fs_layout_type GETATTR) with a new svc_export->ex_flag.
e.g. EX_PNFS_FILE, EX_PNFS_BLOCK, etc.

else, the server can check for the existence of export_op->layout_type (e.g.
call nfsd_layout_verify) on each exported super_block until it finds one
that matches the GETDEVICELIST layout type.

-->Andy

-->Andy

>
> Dean
> >
> > -->Andy
> >
> >     The problem is that getdeviceinfo no longer includes
> >     the current_fh.  Is there a way on the server to get the superblock
> >     without the filehandle? (maybe using something in the
> >     session?)  If not,
> >     then we will have to encode something in the device id that allows
> >     us to
> >     map to the superblock (is the fsid enough?)  Any ideas?
> >
> >     2) Can getdeviceinfo return a device for the wrong layout type?  It
> >     seems that getdeviceinfo returns the layout type, which seems a
> little
> >     silly to me.  If it should return the layout type, and it doesn't
> >     match
> >     the requesting layout type, what should the client do?
> >
> >     3) In draft-19, should bitmap4 not have <>?
> >     bitmap4<> typedef uint32_t bitmap4<>;
> >           ^^^^
> >     For reference, in rfc3530 it does not have the <>. (other ops have
> the
> >     <> added as well)
> >
> >     Thanks,
> >     Dean
> >     _______________________________________________
> >     pNFS mailing list
> >     pNFS at linux-nfs.org <mailto: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/20080206/2e6115ea/attachment.htm