[pnfs] question about getdevlist server code

Muntz, Daniel Dan.Muntz at netapp.com
Thu Nov 1 14:23:38 EDT 2007


The change broke our file-layout-based server...

  -Dan 

-----Original Message-----
From: dean hildebrand [mailto:seattleplus at gmail.com] 
Sent: Wednesday, October 31, 2007 5:41 PM
To: Labiaga, Ricardo
Cc: pnfs at linux-nfs.org; Sager, Mike
Subject: Re: [pnfs] question about getdevlist server code

On Oct 31, 2007 4:56 PM, Labiaga, Ricardo <Ricardo.Labiaga at netapp.com>
wrote:
> Hi Dean,
>
> That's what I get for missing last week's meeting...  Are you saying 
> that by design the getdevlist code we used in Ann Arbor only handles a

> single DS?
No, let me try to explain.

The patches we wrote to handle draft-13 of getdevlist and getdevinfo
were minimal, but they get the job done.  We took a few shortcuts, such
as assuming that there is only 1 deviceid for getdevlist (which is fine
for file layout since all devices come under a single
deviceid)

My paches that move us to the new export interface will correct these
shortcuts.

Sorry for the confusion, I'm sure we are all sick of the word device by
now.....

Dean

>
> - ricardo
>
>
>
> > -----Original Message-----
> > From: dean hildebrand [mailto:seattleplus at gmail.com]
> > Sent: Wednesday, October 31, 2007 4:53 PM
> > To: Sager, Mike
> > Cc: pnfs at linux-nfs.org
> > Subject: Re: [pnfs] question about getdevlist server code
> >
> > The goal was to just get the server working with draft-13.
> >
> > The other reason we didn't spend too much time solving it for the 
> > generic case was that we decided on a new export interface for
> > devices.    It seems there was agreement on this new interface last
> > week and I'm going to start implementing it as soon as I get a
chance.
> >  Right now I'm swamped preparing for supercomputing, but I will send

> > out a patch in the next couple of weeks.
> >
> > Dean
> >
> > On Oct 31, 2007 2:33 PM, Sager, Mike <Mike.Sager at netapp.com> wrote:
> > > Hi,
> > >
> > > I have a question about a recent patch to the 2.6.23-based
> > server.  When
> > > the server is encoding the response to GETDEVLIST in 
> > > nfsd4_encode_getdevlist(), it's doing:
> > >
> > >        if (!nfserr) {
> > >                RESERVE_SPACE(20 + sizeof(nfs4_verifier));
> > >                WRITE64(gdevl->gd_cookie);
> > >                WRITEMEM(&gdevl->gd_verf, sizeof(nfs4_verifier));
> > >
> > >                // num of devlist_item4
> > >                WRITE32(1);
> > >
> > >                WRITE32(gdevl->gd_devlist[0].dev_id);
> > >
> > >                ADJUST_ARGS();
> > >                len = nfsd4_encode_devlist_item(resp, gdevl);
> > >
> > >                RESERVE_SPACE(4);
> > >                WRITE32(gdevl->gd_eof);
> > >                ADJUST_ARGS();
> > >                kfree(gdevl->gd_devlist);
> > >        }
> > >
> > >
> > > It seems to be hardcoding the number of devices to 1.  I'm
> > told there
> > > was some discussion at Bakeathon about this.  Can someone shed 
> > > some light on why it's doing this?
> > >
> > > Thanks,
> > > Mike
> > > _______________________________________________
> > > pNFS mailing list
> > > pNFS at linux-nfs.org
> > > http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs
> > >
> > _______________________________________________
> > pNFS mailing list
> > pNFS at linux-nfs.org
> > http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs
> >
>
_______________________________________________
pNFS mailing list
pNFS at linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs


More information about the pNFS mailing list