Re: NFS problem - close to open cache consistency broken ?

[Thomas Stockheim <tommi@bub-agema.de>]

Lever, Charles wrote:
>>I'm having a problem with NFS caching after updating from Redhat 8 to 
>>Fedora. Sometimes changes to files ( even when done on the 
>>server) just 
>>do not show up. At first we suspected timing problems, but 
>>all machines
>>are synchronized with ntp.
>>
>>Then I found out how to reproduce it:
>>1 server: echo xxxx > testfile
>>2 client: Application 1 on client opens testfile, does 
>>nothing with it - 
>>keeps it open forever ( simple fortran program with an open and an
>>endless loop )
>>3 client: cat testfile  gives xxxx
>>4 server: echo yyyy > testfile
>>5 client: cat testfile  still shows xxxx
>>
>>Its not a file attribute caching problem I think, ls -l shows the
>>correct, updated modificiation time for the file. But the 
>>file contents
>>never get updated. Once I kill the application that was 
>>holding open the 
>>testfile, it still shows the wrong content, but any new changes show 
>>immediately.
>>
>>At first, we tested this on kernel 2.6.11 and 2.6.9. Here, increasing
>>file size by 1 worked to get the updated file contents on the client, 
>>but decreasing file size did not work.
>>
>>6a server: echo zzzzz > testfile
>>7a client: cat testfile  shows zzzzz
>>
>>6b server: echo zzz > testfile
>>7b server: cat testfile  shows xxxx
>>
>>With kernel 2.6.13, any file size changes show the new 
>>content directly,
>>but if the file size stays constant it still does not work.
>>
>>I tried all the mount options, but even turning attribute
>>caching totally off does not seem to help. Mouting as nfsv2 
>>did not help
>>either.
>>
>>I assume its a problem of the client, not the server - mounting the
>>same exports on old redhat 7 with kernel 2.4.2 everything works.
>>
>>If I understand Close-to-open cache consistency right, having the file
>>opened from a different application on the same client should 
>>not be a problem ?
> 
> 
> thomas-
> 
> the client uses mtime and size to detect file changes on the server.  if
> the mtime doesn't change on the server, the clients won't detect any
> data changes.
> 
> what physical file system are you using on the server?
> 
> 

Thanks for the reply, but thats exactly my problem: Mtime does change
on the server, and the client even sees that change ( faster or slower 
depending on caching settings ).

But the data on the client never gets updated.

I tested some more, and this only happens if another application on the
client has the file open for writing.

I think it might have to do something with the data_unstable flag in
nfs_refresh_inode - but I don't understand the kernel code well enough
to see what happens exactly or how to fix it for us.

Thomas



-- 

************************************************************************
**
**  B&B-AGEMA GmbH
**
**  Thomas Stockheim
**  Juelicher Strasse 338
**  D-52070 Aachen
**  Germany
**
**  Tel. (Zentrale):  ++49-(0)241-56878-0
**  Tel. (Durchwahl): ++49-(0)241-56878-31
**  Fax.:             ++49-(0)241-56878-79
**  e-mail:           <tommi@bub-agema.de>
**  Internet:         http://www.bub-agema.de
**
************************************************************************


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs