On Mon, 11 Mar 2013 15:36:38 -0400 "J. Bruce Fields" bfields@fieldses.org wrote:
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.)
I agree that we should return an error, but hadn't considered what error. Given that hardly any NFS clients use them, I'd probably just go with NFS4ERR_SERVERFAULT, and maybe throw a printk or something on the server about enabling share reservations for superblock x:y.
Pavel, as a side note, you may want to consider adding a patch to hook this stuff up in the NFS client as well.