[pnfs] 19 questions

[William A. (Andy) Adamson]

On Feb 6, 2008 2:23 PM, J. Bruce Fields <bfields at fieldses.org> wrote:

> 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.)


presumably the client has performed a GETATTR to find out fs parameters for
mount (including the fs_layout_type if supported). i think this will demand
the server to upcall to mountd. (PUTROOTFH does that no?)

-->Andy

>
>
> But perhaps that's another argument for fixing that aspect of the
> exports system.
>
> --b.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux-nfs.org/pipermail/pnfs/attachments/20080206/4fb2af19/attachment-0001.htm