[linux-cifs-client] lseek(x, x, SEEK_END ) and the infinite dentry cache

[Maximiliano Curia]

On Wednesday 28 December 2005 00:22, Steven French wrote:

> Does this also fail on more recent code (e.g. 2.6.15-rc cifs 1.39 or so)?

I've tried applying the cifs 1.39a to the 2.6.14 kernel tree, and the lseek 
problem was still there. I applied the patch that I had mentioned before (I'm 
attaching it as a proper diff with this message), but it didn't fix the 
problem, not even for read-only files.

So, I commented out the calls to is_size_safe_to_change(), and lseek works 
fine, but I'm still having data-loss problems.

These problems are due to the fact that apparently the cifs client for Linux 
sends blocks of 4096 bytes to the server, of which only 52 bytes need to be 
written, and between the reading of the file and the writing of the record, 
some of those 4096 bytes have been changed by a remote app.

I think that this might be related to an incorrect way of handling lockings 
from dosemu/clipper, and I'm about to write a testcase in C to confirm what's 
going on.

But in any case, why does the cifs client send 4096 bytes over the network, 
when only 52 bytes are being modified? (those bytes aren't locked, neither by 
this client nor by any other)  Is there a way to fix this?

To be fair, I do not see the client sending the block of 4096 bytes, since I'm 
using strace, but I _do_ see the server writing the big block, but it only 
writes 52 bytes when windows clients send a similar request.

-- 
Saludos,
 /\/\ /\ >< `/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cifs_llseek.patch
Type: text/x-diff
Size: 798 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux-cifs-client/attachments/20051229/a1ac5483/cifs_llseek.bin
-------------- next part --------------
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.8/215 - Release Date: 27/12/05