From: Miklos S. <mi...@sz...> - 2012-06-05 16:27:10
|
Kobi Cohen-Arazi <kob...@gm...> writes: > Hi Folks, > > I gave it a try by using lowlevel API and seeing the below behavior. I > think I'm hitting kernel-attr caching and would like to confirm that with > you guys. > > As a reminder, my vfs is serving request for json files. So it is important > that client will read a complete valid json file. > > Here is what I see: > 0. vfs has foo.json with inode 5. > 1. lookup of file "foo.json". Creating a new inode number (10) and caching > the current json buffer for open/read operations. Reporting size 100 bytes > in attr. Setting entry and attr timeout to be "0". I tried all kinds of > values but got the same end result. That lookup might not be followed by > open BTW. Might be just an entry query. > 2. json file (inode 5) has been updated with new value. (That is done on a > different buffer so no worries here). Now foo.json is 120 bytes. > 3. Another lookup comes in for foo.json. Creating a new inode number (11), > caching the json buffer for further open/read. Reporting file size as 120 > bytes. > 4. Open comes in with inode 11, consecutive getattr will report size as 120 > in attr, but when read is done, the results of the buffer size is 100. Just > like in (1) which happened to be invoked few milisecs before. What is application doing? Is it: stat("filename", &stat); fd = open("filename", ...): If so, then nothing guarantees that "filename" on the first call will refer to the same file as the one in the second call. If instead it does fd = open("filename", ...); fstat(fd, &stat); then it is guaranteed that the stat will be for the same file. Thanks, Miklos |