I run 2.6.35 linux kernel on Fedora 13. When I copy new files to a mounted CIFS share (either WinXP or Samba server), oplock is always disabled on these files.
1. sudo mount -t cifs //ip/share /mnt
2. sudo cp new_files /mnt
Oplock status can be observed by adding the following code in cifs_file_aio_write():
cFYI(1, "zn: cifs_file_aio_write(): clientCanCacheAll = %d",
cFYI(1, "zn: cifs_file_aio_write(): clientCanCacheRead = %d",
In my test both clientCanCacheAll and clientCanCacheRead are set to 0 and filemap_fdatawrite() is always called.
I found that before cifs_create() calls cifs_new_fileinfo(), the value of "oplock" variable in cifs_create() is 0x20001 (CIFS_CREATE_ACTION | OPLOCK_EXCLUSIVE). But this value is not used in cifs_new_fileinfo(). Instead, a local "oplock" variable (set to REQ_OPLOCK) is used by cifs_new_fileinfo() to compare with OPLOCK_EXCLUSIVE/OPLOCK_READ. When the comparison fails, clientCanCacheAll/clientCanCacheRead are not set to "true".
cifs_new_fileinfo() is called by cifs_create(), cifs_open() and cifs_lookup(). Maybe it should accept oplock as a function parameter.
Sorry a patch is not provided because I'm new to Samba/CIFS code.
Created attachment 5967 [details]
Thanks for the bug report. Indeed, you're correct! The oplock handling seems broken.
Could you please test the attached fix and report?
I manually applied the patch to 18.104.22.168 tree, and it works fine.
The debug statements I added now print:
fs/cifs/cifsfs.c: zn: cifs_file_aio_write(): clientCanCacheAll = 1
fs/cifs/cifsfs.c: zn: cifs_file_aio_write(): clientCanCacheRead = 1
Patch committed to cifs-2.6 git via commit 23ec47c2ad8115c70a2d5fd1cb3f46b1bf30246a
Can be marked as FIXED (I'm unable to do so..).
Marking FIXED as requested...