<br><br><div class="gmail_quote">On Fri, Aug 21, 2009 at 2:01 PM, Steve French <span dir="ltr"><<a href="mailto:smfrench@gmail.com">smfrench@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br><br><div class="gmail_quote">On Fri, Aug 21, 2009 at 10:48 AM, Jeff Layton <span dir="ltr"><<a href="mailto:jlayton@redhat.com" target="_blank">jlayton@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<br>
</div>As long as you can do so in a non-racy way, then I'm not opposed to<br>
that long-term. The problem though is that I don't have a lot of<br>
confidence in the open file tracking code. It's extremely hard to<br>
follow and definitely has races. I don't think it's really possible to<br>
do what you suggest safely until the open file tracking code has been<br>
fixed.<br>
<br>
For now, I'm pretty sure this set should fix the problems that users<br>
are hitting in the oplock codepath today. I'd like to fix that first<br>
before we embark on a redesign of it.<br>
</blockquote></div><br></div>You may be right that this should be two stages, but your 2nd and 3rd patch<br>are already large, so I doubt that it would grow (and might make it easier<br>to follow and more logical).<br clear="all">
</blockquote></div><br>There is one other thing to consider (which might lean toward your inode<br>based approach rather than what I suggested about tie of the<br>oplock to the file struct for the fid) ... we need to move to 1st attempting<br>
"batch oplocks" (as was discussed in June) to allow safer caching<br>across close (and would also helps with multiple opens from the same<br>client) - this will necessitate making the routine which frees inodes<br>
aware of oplocks. In the short run I was planning on trying this approach<br>(grab one batch oplock on open, and only rely on the other type of oplocks<br>when we can't get or lose the batch oplock) with the smb2 code and<br>
after a few months if it works ok consider fixing the cifs code. In the<br>meantime if we uses patches 2 through 4 as is (one and five are<br>obviously fine), it would be great if we could get at least one more ack.<br>I haven't found any problems yet but they are big.<br>
<br clear="all"><br>-- <br>Thanks,<br><br>Steve<br>