gettattr() cache?

[Nikolaus Rath]

Hello,

I thought that by setting entry_timeout and attr_timeout, the kernel
would cache the result of getattr() calls. However, I am getting
multiple getattr() requests for the same path in intervals much less
than the timeout.

Did I misunderstand something?


Best,

   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Szabolcs Szakacsits]

On Fri, 18 Jul 2008, Nikolaus Rath wrote:

> I thought that by setting entry_timeout and attr_timeout, the kernel
> would cache the result of getattr() calls. However, I am getting
> multiple getattr() requests for the same path in intervals much less
> than the timeout.
>
> Did I misunderstand something?

If the kernel knows the attribute [may] changed then you get more getattrs.

Perhaps you could send the example to reproduce the issue, the fuse debug
log and the fuse/kernel versions you use?

        Szaka

--
NTFS-3G:  http://ntfs-3g.org


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Nikolaus Rath]

Szabolcs Szakacsits <szaka@...> writes:

> On Fri, 18 Jul 2008, Nikolaus Rath wrote:
>
>> I thought that by setting entry_timeout and attr_timeout, the kernel
>> would cache the result of getattr() calls. However, I am getting
>> multiple getattr() requests for the same path in intervals much less
>> than the timeout.
>>
>> Did I misunderstand something?
>
> If the kernel knows the attribute [may] changed then you get more getattrs.
>
> Perhaps you could send the example to reproduce the issue, the fuse debug
> log and the fuse/kernel versions you use?

Sure. You can just use one of the fuse provided examples and run "ls;
ls" in the mounted directory.

I have attached a slightly modified python example that prints out the
time whenever getattr is called. Here is the output:

$ ./mirror.py /home/nikratio/test -fs
getattr for / at 1216400067.29
getattr for /.Trash at 1216400067.3
getattr for /.Trash-1000 at 1216400067.3
getattr for /.Trash at 1216400067.34
getattr for /.Trash-1000 at 1216400067.34
getattr for / at 1216400075.44
getattr for / at 1216400075.45


The last two lines appeared when I ran "ls; ls" in the
/home/nikratio/test directory.

With debugging output, it says:

unique: 8, opcode: GETATTR (3), nodeid: 1, insize: 56
getattr for / at 1216400261.25
   unique: 8, error: 0 (Success), outsize: 112
unique: 9, opcode: OPENDIR (27), nodeid: 1, insize: 48
   unique: 9, error: 0 (Success), outsize: 32
unique: 10, opcode: READDIR (28), nodeid: 1, insize: 80
   unique: 10, error: 0 (Success), outsize: 816
unique: 11, opcode: READDIR (28), nodeid: 1, insize: 80
   unique: 11, error: 0 (Success), outsize: 16
unique: 12, opcode: RELEASEDIR (29), nodeid: 1, insize: 64
   unique: 12, error: 0 (Success), outsize: 16
unique: 13, opcode: GETATTR (3), nodeid: 1, insize: 56
getattr for / at 1216400261.26
   unique: 13, error: 0 (Success), outsize: 112
unique: 14, opcode: OPENDIR (27), nodeid: 1, insize: 48
   unique: 14, error: 0 (Success), outsize: 32
unique: 15, opcode: READDIR (28), nodeid: 1, insize: 80
   unique: 15, error: 0 (Success), outsize: 816
unique: 16, opcode: READDIR (28), nodeid: 1, insize: 80
   unique: 16, error: 0 (Success), outsize: 16
unique: 17, opcode: RELEASEDIR (29), nodeid: 1, insize: 64
   unique: 17, error: 0 (Success), outsize: 16


Fuse version is 2.7.2 - how do I figure out the version of the kernel
module?


Best,

   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Szabolcs Szakacsits]

On Fri, 18 Jul 2008, Nikolaus Rath wrote:

> Szabolcs Szakacsits <szaka@...> writes:
> > On Fri, 18 Jul 2008, Nikolaus Rath wrote:
> >
> >> I thought that by setting entry_timeout and attr_timeout, the kernel
> >> would cache the result of getattr() calls. However, I am getting
> >> multiple getattr() requests for the same path in intervals much less
> >> than the timeout.
> >>
> >> Did I misunderstand something?
> >
> > If the kernel knows the attribute [may] changed then you get more getattrs.
> >
> > Perhaps you could send the example to reproduce the issue, the fuse debug
> > log and the fuse/kernel versions you use?
>
> Sure. You can just use one of the fuse provided examples and run "ls;
> ls" in the mounted directory.

I can't reproduce with any of them. Only '/' gets multiply requests and I
guess there is a reason for it.
 

> I have attached a slightly modified python example that prints out the
> time whenever getattr is called. Here is the output:
>
> $ ./mirror.py /home/nikratio/test -fs
> getattr for / at 1216400067.29
> getattr for /.Trash at 1216400067.3
> getattr for /.Trash-1000 at 1216400067.3
> getattr for /.Trash at 1216400067.34
> getattr for /.Trash-1000 at 1216400067.34
> getattr for / at 1216400075.44
> getattr for / at 1216400075.45

./mirror.py indeed seems to ignore the caching options.
 

> The last two lines appeared when I ran "ls; ls" in the
> /home/nikratio/test directory.
>
> With debugging output, it says:
>
> unique: 8, opcode: GETATTR (3), nodeid: 1, insize: 56
> getattr for / at 1216400261.25
>    unique: 8, error: 0 (Success), outsize: 112
> unique: 9, opcode: OPENDIR (27), nodeid: 1, insize: 48
>    unique: 9, error: 0 (Success), outsize: 32
> unique: 10, opcode: READDIR (28), nodeid: 1, insize: 80
>    unique: 10, error: 0 (Success), outsize: 816
> unique: 11, opcode: READDIR (28), nodeid: 1, insize: 80
>    unique: 11, error: 0 (Success), outsize: 16
> unique: 12, opcode: RELEASEDIR (29), nodeid: 1, insize: 64
>    unique: 12, error: 0 (Success), outsize: 16
> unique: 13, opcode: GETATTR (3), nodeid: 1, insize: 56
> getattr for / at 1216400261.26
>    unique: 13, error: 0 (Success), outsize: 112
> unique: 14, opcode: OPENDIR (27), nodeid: 1, insize: 48
>    unique: 14, error: 0 (Success), outsize: 32
> unique: 15, opcode: READDIR (28), nodeid: 1, insize: 80
>    unique: 15, error: 0 (Success), outsize: 816
> unique: 16, opcode: READDIR (28), nodeid: 1, insize: 80
>    unique: 16, error: 0 (Success), outsize: 16
> unique: 17, opcode: RELEASEDIR (29), nodeid: 1, insize: 64
>    unique: 17, error: 0 (Success), outsize: 16

It looks fine (regarding to getattr, directory content caching is not
supported, afaik). '/' is not cached for some reason which is probably
intentional.
 
> Fuse version is 2.7.2 - how do I figure out the version of the kernel
> module?

The kernel version is enough unless the FUSE kernel module was installed
from a FUSE package.

        Szaka

--
NTFS-3G:  http://ntfs-3g.org


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Nikolaus Rath]

Szabolcs Szakacsits <szaka@...> writes:

> On Fri, 18 Jul 2008, Nikolaus Rath wrote:
>> Szabolcs Szakacsits <szaka@...> writes:
>> > On Fri, 18 Jul 2008, Nikolaus Rath wrote:
>> >
>> >> I thought that by setting entry_timeout and attr_timeout, the kernel
>> >> would cache the result of getattr() calls. However, I am getting
>> >> multiple getattr() requests for the same path in intervals much less
>> >> than the timeout.
>> >>
>> >> Did I misunderstand something?
>> >
>> > If the kernel knows the attribute [may] changed then you get more getattrs.
>> >
>> > Perhaps you could send the example to reproduce the issue, the fuse debug
>> > log and the fuse/kernel versions you use?
>>
>> Sure. You can just use one of the fuse provided examples and run "ls;
>> ls" in the mounted directory.
>
> I can't reproduce with any of them. Only '/' gets multiply requests
> and I guess there is a reason for it.

I have only checked / with the non-python examples. But you're right,
with the C examples, only / gets multiple requests.

>> I have attached a slightly modified python example that prints out the
>> time whenever getattr is called. Here is the output:
>>
>> $ ./mirror.py /home/nikratio/test -fs
>> getattr for / at 1216400067.29
>> getattr for /.Trash at 1216400067.3
>> getattr for /.Trash-1000 at 1216400067.3
>> getattr for /.Trash at 1216400067.34
>> getattr for /.Trash-1000 at 1216400067.34
>> getattr for / at 1216400075.44
>> getattr for / at 1216400075.45
>
> ./mirror.py indeed seems to ignore the caching options.

Csaba, do you have an idea why this happens when using the python
interface?


> It looks fine (regarding to getattr, directory content caching is not
> supported, afaik). '/' is not cached for some reason which is probably
> intentional.

Hmm. Does anyone know the exact intentions?


Best,

   -Nikolaus

--
 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel