Re: [fuse-devel] Issues when dealing with cached buffers

[Kobi Cohen-A. <kob...@gm...>]

- Kobi


On Tue, Jun 5, 2012 at 9:37 AM, Kobi Cohen-Arazi
<kob...@gm...>wrote:

>
> - Kobi
>
>
> On Tue, Jun 5, 2012 at 9:27 AM, Miklos Szeredi <mi...@sz...> wrote:
>
>> 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.
>>
>
> Good point. The client in that case is Apache. It means that httpd is the
> one accessing the vfs and serving http request to the json files. So it
> might be doing (intentionally or not) something like the former rather than
> the later.
>


Thinking about it a bit more, I don't think I understand why fuse would not
treat it as a 2 separate files since I am providing different inodes. In
another words, even with the following sequence:

       stat("filename", &stat);
//  the above is performing lookup for {parent-inode, "filename"}
// providing fuse with inode 10 with size 100 for attributes.

// I can see sometimes another lookup here.
// Let's say file size now changed to 120.
// providing fuse with inode 11 with size 120 for attributes.

       fd = open("filename", ...):
// the above is triggering lookup  for {parent-inode, "filename"}
// providing fuse with inode 12 with size 120 for attributes.
// open is called for inode 12. That inode is attached to a 120 bytes
payload.
// read is called, but only 100 bytes are read.

Since I provide a different inode to fuse everytime, I thought it would
treat it as a whole new and separate entity/entry.
But it's not. For some reason it would "remember" that lookup that returned
100 bytes.
It is as that entry is still valid and even *new* inodes of the same
{parent, fname} would not help in that case.

I might be missing something here.

Kobi


>
> Kobi.
>
>
>> Thanks,
>> Miklos
>>
>
>