----- Original Message ----- From: "Paul Patrick Carpio Prantilla" <[EMAIL PROTECTED]> To: "PLUG" <[EMAIL PROTECTED]> Sent: Wednesday, May 05, 2004 10:32 PM Subject: Re: [plug] Caching Issues in NFS
> Yes, actually this was the first thing I tried. It didn't seem to give > the desired effect though (using the "time" command, it was quite > obvious that it was still caching). So after reading a bit more, I > assumed that "attribute caching" was different than total file caching. damn... silly me also... sorry for that... noac option is to *disable* file attribute caching and it is totally different from file data caching... allow me to explain what is attribute caching and what are the solutions to your problem... on an nfs environment, each file in a filesystem that has been accessed by a client caches a file attribute information (eg. last modification time and size)... to detect file changes quickly yet efficiently, the nfs protocol uses *close-to-open* cache semantics... when a client opens a file, it uses a *GETATTR* operation to check that the file still exists and any cached data it has is still up-to-date... a client checks back with the server only after a *timeout* indicates that the file's attributes may be stale... during such a a check, if the server's version of the attributes has changed, the client *purge* its cache...take note that, a client can delay writes to a file indefinitely... when a client closes a file, it flushes all pending modifications to the file to the server... it might take some time (delayed writes) before an application running on one client sees changes made by applications on other clients... delayed writes and the client's attribute cache timeout can delay detection changes on the server by many seconds while a file is open.... the *noac* mount option prevents the client from caching file attributes... take note that *noac* causes a client to process all writes to that filesystem synchronously... just as the *sync* mount option does... when the *noac* option is in effect, clients *STILL* cache file data as long as they detect that a file has not changed on the server... now here comes the solution... in order to acquire direct, uncached access to data on a server... using the *noac* mount option is not good enough because linux nfs client *still caches reads*... here are the two solutions that i recommend to you: 1. to ensure your application sees the server's version of a file's data and not potentially stale data cached by the client, your application can *LOCK* and *UNLOCK* the file... this pushes all pending write operations back to the server and purges any remaining cache data... so that the next read operation will go back to the server rather than reading from a local cache... 2. linux kernel supports *DIRECT I/O* to nfs files when an application opens a file with the O_DIRECT flag is set... direct i/o is a feature designed to benefit applications that manage their own data cache (just as what you are experimenting right now)... when this feature is enabled, an application's read and write system calls are translated directly into nfs read and write operations... the linux kernel *never* caches the results of any read or write when a file is opened with this flag... so therefore, applications always get exactly what's on the server and not on its local cache... so i hope this will solve your problem and good luck to your client-side caching algorithm high hits :-> fooler. -- Philippine Linux Users' Group (PLUG) Mailing List [EMAIL PROTECTED] (#PLUG @ irc.free.net.ph) Official Website: http://plug.linux.org.ph Searchable Archives: http://marc.free.net.ph . To leave, go to http://lists.q-linux.com/mailman/listinfo/plug . Are you a Linux newbie? To join the newbie list, go to http://lists.q-linux.com/mailman/listinfo/ph-linux-newbie
