[pnfs] 19 questions
Glasgow_Jason at emc.com
Glasgow_Jason at emc.com
Wed Feb 6 14:51:22 EST 2008
GETDEVICELIST does take a currentfh in draft-19.
struct GETDEVICELIST4args {
/* CURRENT_FH: object belonging to the file system */
layouttype4 gdla_layout_type;
/* number of deviceIDs to return */
count4 gdla_maxdevices;
nfs_cookie4 gdla_cookie;
verifier4 gdla_cookieverf;
};
-Jason
________________________________
From: pnfs-bounces at linux-nfs.org [mailto:pnfs-bounces at linux-nfs.org] On
Behalf Of William A. (Andy) Adamson
Sent: Wednesday, February 06, 2008 2:46 PM
To: Dean Hildebrand
Cc: pnfs at linux-nfs.org
Subject: Re: [pnfs] 19 questions
On Feb 6, 2008 2:27 PM, Dean Hildebrand <seattleplus at gmail.com> wrote:
William A. (Andy) Adamson wrote:
>
>
> On Feb 6, 2008 1:26 PM, Dean Hildebrand <seattleplus at gmail.com
> <mailto: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>
> > <mailto: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.
Hmmm, the problem I see is that there could be multiple exported file
systems supporting the same layout type.
this is a good question. if the MDS exports two file layout GPFS
filesystems, one could expect a device ID to be "global" across both
file systems.
but, if the MDS export one file layout GPFS file system and one spNFS
file system - no way!
what does a "global device id" mean? global to layout type/MDS? no.
global to layout type/vendor?
i say we add a currentfh to GETDEVICELIST and be done with it.
-->Andy
So matching the exported
layout type to the getdeviceinfo layout type isn't sufficient.
You
would have to call export_op->getdeviceinfo on each exported
file system
that matches the layout type until you find one that recognizes
the
deviceid. ugh.
So I think that we still need to somehow encapsulate which
export we are
referring to in the deviceid. But if fsid's can be up to 24
bytes long,
we have a problem.
Dean
> > 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>
> <mailto: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/4495dce6/attachment.htm
More information about the pNFS
mailing list