On Thu, Dec 10, 2009 at 09:21:30PM +0200, Benny Halevy wrote:
> On Dec. 10, 2009, 21:04 +0200, "J. Bruce Fields" <bfields@xxxxxxxxxxxxxx> wrote:
> > On Thu, Dec 10, 2009 at 08:53:08PM +0200, Benny Halevy wrote:
> >> On Dec. 10, 2009, 19:30 +0200, " J. Bruce Fields" <bfields@xxxxxxxxxxxxxx> wrote:
> >>> On Mon, Dec 07, 2009 at 11:32:10AM +0200, Benny Halevy wrote:
> >>>> +static __be32
> >>>> +nfsd4_getdevinfo(struct svc_rqst *rqstp,
> >>>> + struct nfsd4_compound_state *cstate,
> >>>> + struct nfsd4_pnfs_getdevinfo *gdp)
> >>>> +{
> >>>> + struct super_block *sb;
> >>>> + struct svc_export *exp = NULL;
> >>>> + u32 fsidv = gdp->gd_devid.fsid;
> >>>> + int status;
> >>>> +
> >>>> + dprintk("%s: layout_type %u dev_id %llx:%llx maxcnt %u\n",
> >>>> + __func__, gdp->gd_layout_type, gdp->gd_devid.fsid,
> >>>> + gdp->gd_devid.devid, gdp->gd_maxcount);
> >>>> +
> >>>> + status = nfserr_inval;
> >>>> + exp = rqst_exp_find(rqstp, FSID_NUM, &fsidv);
> >>> As I said before, this seems to require an fsid= option on every pnfs
> >>> export. We shouldn't need that.
> >> If there a better way to get to the sb given the fsid?
> >> Since we don't have a current_fh for getdeviceinfo the alternative
> >> might be to map the deviceids to sb's in the generic layer.
> >
> > Does the deviceid even need to persist over reboots? If not, then just
> > an index into an in-memory table might be good enough. If it does need
> > to persist, then I guess we should look at the filehandle-decoding code
> > for inspiration.
>
> No, the deviceids need not persist across reboots and we're free to put
> anything we want in the major part of the deviceid, leaving the minor
> for the filesystem-unique ID.
In that case, managing deviceid's isn't any harder than stateid's or the
rest--just make up something and remember it in some in-memory data
structure.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
