[PATCH 12/16] nfsd4: make readonly access depend on pseudoflavor

J. Bruce Fields bfields at fieldses.org
Mon Jun 18 11:59:42 EDT 2007


On Tue, May 22, 2007 at 05:00:57PM +1000, Neil Brown wrote:
> On Friday May 18, bfields at fieldses.org wrote:
> > From: J. Bruce Fields <bfields at citi.umich.edu>
> > 
> > Allow readonly access to vary depending on the pseudoflavor, using the
> > flag passed with each pseudoflavor in the export downcall.  The rest of
>                                                               ^^^^^^^^^^^
> > the flags are ignored for now, though some day we might also allow id
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > squashing to vary based on the flavor.
> 
> This begs the question:  Should we allow those flags to be set.
> 
> i.e. if a per-pseudoflavour flag is set that we don't support,
> should we just return an error so that the admin knows that their
> configuration is not supported.
> And how do you tell if a flag is set or not...
> Maybe we should complain if the per-pseudoflavour flags are different
> to the export-wide flags on any bit other than readonly?

That makes sense to me; done.

> Different id squashing?  Maybe, but it would be awkward to squash to a
> different id.  I suspect there would be no call for that.  But having
> different values for the allsquash and rootsquash flags might make
> sense one day.

Yes, so I've gone ahead and implemented that.

I also took a quick look at local Solaris and NetApp documentation, and
found that the flags they allow to vary per-flavor are essentially the
same (ro and id-squashing flags).

I've also added support for secinfo to the nfsd.export cache show
method and fixed exp_find and friends (as discussed before).  My most
recent patch series is available from the server-secinfo branch at

	git://linux-nfs.org/~bfields/linux.git server-secinfo

Let me know when/if you'd like another mailbomb.  (It's 20 patches at
this point.)

--b.


More information about the NFSv4 mailing list