On Mon, Mar 11, 2013 at 03:05:40PM -0400, Jeff Layton wrote:
> knfsd has some code already to handle share reservations internally.
> Nothing outside of knfsd is aware of these reservations, of course so
> moving to a vfs-level object for it would be a marked improvement.
>
> It doesn't look like this patch removes any of that old code though. I
> think it probably should, or there ought to be some consideration of
> how this new stuff will mesh with it.
>
> I think you have 2 choices here:
>
> 1/ rip out the old share reservation code altogether and require that
> filesystems mount with -o sharemand or whatever if they want to allow
> their enforcement
>
> 2/ make knfsd fall back to using the internal share reservation code
> when the mount option isn't enabled
>
> Personally, I think #1 would be fine, but Bruce may want to weigh in on
> what he'd prefer.
#1 sounds good. Clients that use deny bits are few. My preference
would be to return an error to such clients in the case share locks
aren't available.
(We're a little out of spec there, so I'm not sure which error. I think
the goal is to notify a human there's a problem with minimal collateral
damange.
NFS4ERR_SERVERFAULT ("I'm a buggy server, sorry about that!") would
probably result in an IO error to the application.
SHARE_DENIED strikes me as unsafe: an application would be in its rights
not to even check for that e.g. in the case of an exclusive create.
Maybe DELAY? Kind of ridiculous, but blocking the application
indefinitely would probably get someone's attention quickly enough
without doing any damnage.)
--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
