Re: [PATCH RFC v0 05/49] pnfsd: introduce pnfsd header files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Sep 29, 2013 at 05:35:53AM -0700, Christoph Hellwig wrote:
> On Sun, Sep 29, 2013 at 05:21:30AM -0700, Christoph Hellwig wrote:
> > > Bruce - are you ok with moving the pnfs interface definitions to
> > > include/linux/exportfs.h along with struct export_operations?
> > > 
> > > In fact we can actually extend struct export_operations rather
> > > than adding pnfs_export_operations...
> > 
> > Yes, it probably should go into the export ops, although the actual
> > method signatures might need to be made a litle less nfs-specific for
> > that.
> 
> I jsut took a brief look over the diff for the whole series in the git
> tree and the old tree that still had block and exofs servers and have
> revised my opinion a little bit:
> 
> 
>  - the should be a layout_type field in struct export_operations,
>    indicating that a filesystem support some sort of pnfs-like export.
>  - there should be a struct pnfs_operations, but it should be confined
>    to fs/nfsd: each layout can be a separate loadable module and gets
>    registered there.  For the initial file layout that module is
>    self-contained, but for e.g. block or objects it would have
>    call into the filesystem through export_ops, although way lower level
>    than the NFS XDR level, e.g. for block there would be one of to get
>    the extent map, and one to allocate an extent.

That sounds OK to me.

My (possibly faulty) memory of how the xdr-encoding-in-the-fs came
about: I think people weren't willing to commit to any reasonable upper
limit on the size of the layout.  So they originally considered
something more like readdir that would loop over extents and pass them
to a callback for encoding.  But xdr isn't complicated so you could
instead give the filesystem a simple library of xdr encoders to call.

But it sounds like that's not exactly what got implemented.  And maybe
nobody actually has such big layouts.

> This way we alsod avoid the dependcy on nfsd in the filesystems that the
> cureent version introduces.

Ugh--thanks for catching that.

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




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux