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! > 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! -- Best regards, Pavel Shilovsky.
Attachment:
mtime_problem_samba-3-4-7.pcap
Description: Binary data
