On Sat, 11 Sep 2010 00:16:41 +0400
Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote:
> 2010/9/10 Jeff Layton <jlayton@xxxxxxxxx>:
> > filemap_fdatawrite starts up a flush of the writes but doesn't wait for
> > it to complete. The data is cached however. If there's a problem
> > writing out the data to the server that gets reported at fsync or
> > close. That's consistent with POSIX. We're not required to report
> > errors flushing the data until that time.
>
> In this case we are not flushing all the cached data - we are doing
> write (via call from the userspace) and the application wants to know
> the right results of it. As I mentioned above, if we have mandatory
> byte-range lock from another client on this range of the file, the
> writing fails but the application won't know about it!
>
So what? Why should the writer know anything about whether it succeeds
before a flush or close occurs? POSIX does not mandate that. If you are
able to report an error at write time, then that's fine. It's not
required however.
> > I see both oplocks being broken:
> >
> > 0x0001: frames 57 and 60
> > 0x0002: frames 65 and 66
> >
>
> The first it is downgrading client1's oplock to Level II when client2
> opens the same file (client2 gets Oplock Level II) too), but the
> second - downgrading to None - I think it should be for every client
> opened the same file. But it the capture:
>
> client2 writes to the file and gets Oplock break to None, but client1
> doesn't get it and still think that it can read from a cache (because
> it has Oplock Level II).
>
> It is with Samba-4.0.0-alpha11. I tested it with Samba 3.4 and got
> another results (the capture is in attachment) - the server downgrades
> the oplock of client1 to None when client2 opens the file (client2
> gets Oplock None too) - it's right!
>
That's not how I read this:
57: server downgrades oplock on 0x0001 to level 2
60: client drops oplock altogether for 0x0001 (note that it replies
with oplock level 0)
65: server revokes oplock on 0x0002 altogether
66: client "acks" the oplock break
At that point there are no more oplocks held. Why would the server need
to send another oplock break?
--
Jeff Layton <jlayton@xxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
