<html><body>
<p><tt><font size="2">"J. Bruce Fields" <bfields@fieldses.org> wrote</font></tt><br>
<tt><font size="2">> On Mon, Mar 11, 2013 at 04:08:44PM -0400, Jeff Layton wrote:<br>
> > On Mon, 11 Mar 2013 15:36:38 -0400<br>
> > "J. Bruce Fields" <bfields@fieldses.org> wrote:<br>
> > > > It doesn't look like this patch removes any of that old code though. I<br>
> > > > think it probably should, or there ought to be some consideration of<br>
> > > > how this new stuff will mesh with it.<br>
> > > > <br>
> > > > I think you have 2 choices here:<br>
> > > > <br>
> > > > 1/ rip out the old share reservation code altogether and require that<br>
> > > > filesystems mount with -o sharemand or whatever if they want to allow<br>
> > > > their enforcement<br>
> > > > <br>
> > > > 2/ make knfsd fall back to using the internal share reservation code<br>
> > > > when the mount option isn't enabled<br>
> > > > <br>
> > > > Personally, I think #1 would be fine, but Bruce may want to weigh in on<br>
> > > > what he'd prefer.<br>
> > > <br>
> > > #1 sounds good. Clients that use deny bits are few. My preference<br>
> > > would be to return an error to such clients in the case share locks<br>
> > > aren't available.<br>
> > > <br>
> > > (We're a little out of spec there, so I'm not sure which error. I think<br>
> > > the goal is to notify a human there's a problem with minimal collateral<br>
> > > damange.<br>
> > > <br>
> > > NFS4ERR_SERVERFAULT ("I'm a buggy server, sorry about that!") would<br>
> > > probably result in an IO error to the application.<br>
> > > <br>
> > > SHARE_DENIED strikes me as unsafe: an application would be in its rights<br>
> > > not to even check for that e.g. in the case of an exclusive create.<br>
</font></tt><br>
<tt><font size="2">Hmm, shouldn't the client catch that with a "default" case at least?<br>
</font></tt><br>
<tt><font size="2">> > > Maybe DELAY? Kind of ridiculous, but blocking the application<br>
> > > indefinitely would probably get someone's attention quickly enough<br>
> > > without doing any damnage.)<br>
> > > <br>
> > <br>
> > I agree that we should return an error, but hadn't considered what<br>
> > error. Given that hardly any NFS clients use them, I'd probably just go<br>
> > with NFS4ERR_SERVERFAULT, and maybe throw a printk or something on the<br>
> > server about enabling share reservations for superblock x:y.<br>
> <br>
> Sounds reasonable.<br>
</font></tt><br>
<tt><font size="2">If I'm understanding, the suggestion is a mount option to enable share reservations and if so, they will be mandatory?</font></tt><br>
<br>
<tt><font size="2">In that case, perhaps we want to keep the existing knfsd code as a fallback, someone might want to support them, but not have them be mandatory (if nothing else, you may cause consternation from folks running pynfs against a default configured knfsd server....).</font></tt><br>
<br>
<tt><font size="2">In the Ganesha project, we provide an internal implementation of share reservations for when the underlying system can not support them.</font></tt><br>
<br>
<tt><font size="2">Another bit to consider, does lockd provide share reservations for NLM?</font></tt><br>
<br>
<tt><font size="2">Frank</font></tt><br>
</body></html>