[linux-cifs-client] More tests on several clients for the same file

[Maximiliano Curia]

We've developed yet another test-case in order to see what our problem
with data-loss is (I'm attaching the code). It opens a file, and when
the user presses ENTER, a newline is appended to the end of the file
(locking the whole file to do this, then unlocking it).

You can test this by running it over a cifs mounted resource in two
different machines, or just running it in one machine and using "echo
blablabla >> locktest.txt" in another.  Unfortunately it's not possible
to use any windows clients to test it.

So, if you open this program in machine A, and then write some info into
the file from machine B, and then press enter on machine A again:

1. With standard cifs/kernel, A overwrites the data from B, never even
knowing that the file grew.
2. With the llseek patch (and commenting out the calls to
"is_size_safe_to_change"), A overwrites the data, but leaving \0 chars
in the place where the added data should be. (i.e. size is correct, data
is not)
3. With the previous patch & commenting out the "PageUptodate" check
that is done inside the cifs_prepare_write function, A sees B's changes
and nothing is lost (but other test cases fail).

Now, the solution proposed in 3. is not really good, because other test
cases still fail, like running the "tlock" program -mentioned in a
previous message- twice in the same machine.

But this seems to show what's really going on: with the current cifs
code, a client with an open file never gets to know if this file has
grown (until it's closed and opened again); adding the llseek function
makes the client see the change in the file size, but since the whole
page is sent to the server and the rest of the page-data is not
refreshed, the empty data is filled with \0.

Possible solutions to this last problem would be to make the client send
only the changed bytes (and not the whole page), or find a way to
correctly update the pages.

I'd say that the first one would be better, since it leaves the paging
work to the server, and the amount of data transmitted is kept to what's
really needed instead of a whole page for just a few bytes.  But it
might be that the second is simpler to implement.


PS: the file is compiled with: gcc -o simplelock -lreadline simplelock.c

-- 
Saludos,
 /\/\ /\ >< `/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: simplelock.c
Type: text/x-csrc
Size: 2283 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux-cifs-client/attachments/20051230/50e1e808/simplelock.bin
-------------- next part --------------
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.9/216 - Release Date: 29/12/05