[pnfs] 19 questions

[J. Bruce Fields]

On Wed, Feb 06, 2008 at 02:11:50PM -0500, William A. (Andy) Adamson wrote:
> 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.

The server doesn't generally have a complete list of exports.  It
discovers them on demand.  (For example, exp_find_key() will map a fsid
to an export by doing an upcall to mountd if necessary.)

But perhaps that's another argument for fixing that aspect of the
exports system.

--b.