Low-level API, stuck in loop node id: 1

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Low-level API, stuck in loop node id: 1

Jason Miesionczek
Hi,

So I am working on a filesystem that interacts with a file-sharing web service. I am trying to get a basic directory listing working. When I mount the service and start fuse, I see that it is trying over and over again to LOOKUP, OPENDIR, GETATTR, READDIR for nodeid: 1. when i try to do an ls within the mountpoint i get an Input/Output error. 

Is there something simple that I am missing? or is there something deep in the bowels of what i am trying to do? Any hints as to where I should start looking?

I will gladly supply any code that you guys would like to see, just let me know, didn't want to start pasting a bunch of random stuff without knowing what exactly you would want to see.

Thanks in advance,
Jason


unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0                        
INIT: 7.26                                                                         
flags=0x001ffffb                                                                   
max_readahead=0x00020000                                                           
   INIT: 7.26                                                                      
   flags=0x00009029                                                                
   max_readahead=0x00020000                                                        
   max_write=0x00020000                                                            
   max_background=0                                                                
   congestion_threshold=0                                                          
   time_gran=1                                                                     
   unique: 1, success, outsize: 80                                                 
[New Thread 0x7fffeb51e700 (LWP 17734)]                                            
unique: 2, opcode: ACCESS (34), nodeid: 1, insize: 48, pid: 8406                   
   unique: 2, error: -38 (Function not implemented), outsize: 16                   
unique: 3, opcode: OPENDIR (27), nodeid: 1, insize: 48, pid: 2919                  
   unique: 3, success, outsize: 32                                                 
[New Thread 0x7fffead1d700 (LWP 17735)]                                            
unique: 4, opcode: LOOKUP (1), nodeid: 1, insize: 45, pid: 17726                   
unique: 5, opcode: GETATTR (3), nodeid: 1, insize: 56, pid: 2919                   
   unique: 5, success, outsize: 120                                                
   unique: 4, success, outsize: 144                                                
unique: 6, opcode: READDIR (28), nodeid: 1, insize: 80, pid: 2919                  
[New Thread 0x7fffea51c700 (LWP 17736)]                                            
[Thread 0x7fffea51c700 (LWP 17736) exited]                                         
   unique: 6, success, outsize: 1208                                               
unique: 7, opcode: LOOKUP (1), nodeid: 1, insize: 57, pid: 17725                   
   unique: 7, success, outsize: 144                                                
unique: 8, opcode: LOOKUP (1), nodeid: 1, insize: 52, pid: 17727                   
   unique: 8, success, outsize: 144                                                
unique: 9, opcode: LOOKUP (1), nodeid: 1, insize: 47, pid: 8406                    
   unique: 9, success, outsize: 144                                                
unique: 10, opcode: READDIR (28), nodeid: 1, insize: 80, pid: 2919                 
[New Thread 0x7fffea51c700 (LWP 17737)]                                            
[Thread 0x7fffea51c700 (LWP 17737) exited]                                         
   unique: 10, success, outsize: 1144                                              
unique: 11, opcode: RELEASEDIR (29), nodeid: 1, insize: 64, pid: 0                 
   unique: 11, success, outsize: 16                                                
unique: 12, opcode: LOOKUP (1), nodeid: 1, insize: 52, pid: 8406                   
unique: 13, opcode: OPENDIR (27), nodeid: 1, insize: 48, pid: 2919                 
   unique: 13, success, outsize: 32                                                
   unique: 12, success, outsize: 144                                               
unique: 14, opcode: LOOKUP (1), nodeid: 1923364088320697807, insize: 46, pid: 8406 
unique: 15, opcode: GETATTR (3), nodeid: 1, insize: 56, pid: 2919                  
   unique: 15, success, outsize: 120                                               
   unique: 14, success, outsize: 144                                               
unique: 16, opcode: READDIR (28), nodeid: 1, insize: 80, pid: 2919                 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Low-level API, stuck in loop node id: 1

Nikolaus Rath
On Jul 25 2017, Jason Miesionczek <[hidden email]> wrote:
> Hi,
>
> So I am working on a filesystem that interacts with a file-sharing web
> service. I am trying to get a basic directory listing working. When I mount
> the service and start fuse, I see that it is trying over and over again to
> LOOKUP, OPENDIR, GETATTR, READDIR for nodeid: 1. when i try to do an ls
> within the mountpoint i get an Input/Output error.

nodeid = 1 is the root directory of your filesystem, i.e. the
mountpoint.

I would guess that whatever you are returning from lookup, getattr or
readdir is invalid.

Try hardcoding something simple for this special case (e.g. use the code
from example/hello_ll.c).


Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Low-level API, stuck in loop node id: 1

Jason Miesionczek


On Wed, Jul 26, 2017 at 4:59 AM, Nikolaus Rath <[hidden email]> wrote:
On Jul 25 2017, Jason Miesionczek <[hidden email]> wrote:
> Hi,
>
> So I am working on a filesystem that interacts with a file-sharing web
> service. I am trying to get a basic directory listing working. When I mount
> the service and start fuse, I see that it is trying over and over again to
> LOOKUP, OPENDIR, GETATTR, READDIR for nodeid: 1. when i try to do an ls
> within the mountpoint i get an Input/Output error.

nodeid = 1 is the root directory of your filesystem, i.e. the
mountpoint.

I would guess that whatever you are returning from lookup, getattr or
readdir is invalid.

Try hardcoding something simple for this special case (e.g. use the code
from example/hello_ll.c).


Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel

Ok, so I fixed my implementation of getattr and now it doesn't loop endlessly anymore. Now the next issue is as soon as i try to ls the mountpoint, i immediately get a I/O error. No additional debug logs are shown in the console.

unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
INIT: 7.26
flags=0x001ffffb
max_readahead=0x00020000
   INIT: 7.26
   flags=0x00009029
   max_readahead=0x00020000
   max_write=0x00020000
   max_background=0
   congestion_threshold=0
   time_gran=1
   unique: 1, success, outsize: 80
unique: 2, opcode: ACCESS (34), nodeid: 1, insize: 48, pid: 8406
   unique: 2, error: -38 (Function not implemented), outsize: 16
unique: 3, opcode: OPENDIR (27), nodeid: 1, insize: 48, pid: 2919
   unique: 3, success, outsize: 32
unique: 4, opcode: LOOKUP (1), nodeid: 1, insize: 45, pid: 30087
unique: 5, opcode: GETATTR (3), nodeid: 1, insize: 56, pid: 2919
   unique: 4, error: -2 (No such file or directory), outsize: 16
unique: 6, opcode: LOOKUP (1), nodeid: 1, insize: 57, pid: 30088
   unique: 5, success, outsize: 120
unique: 7, opcode: RELEASEDIR (29), nodeid: 1, insize: 64, pid: 0
   unique: 7, success, outsize: 16
   unique: 6, error: -2 (No such file or directory), outsize: 16
unique: 8, opcode: LOOKUP (1), nodeid: 1, insize: 52, pid: 30089
   unique: 8, error: -2 (No such file or directory), outsize: 16
unique: 9, opcode: LOOKUP (1), nodeid: 1, insize: 47, pid: 8406
   unique: 9, error: -2 (No such file or directory), outsize: 16

Any other pointers to where i should be looking? I can send the contents of the various functions if that might help.

Thanks again,
Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Low-level API, stuck in loop node id: 1

Jason Miesionczek


On Wed, Jul 26, 2017 at 1:39 PM, Jason Miesionczek <[hidden email]> wrote:


On Wed, Jul 26, 2017 at 4:59 AM, Nikolaus Rath <[hidden email]> wrote:
On Jul 25 2017, Jason Miesionczek <[hidden email]> wrote:
> Hi,
>
> So I am working on a filesystem that interacts with a file-sharing web
> service. I am trying to get a basic directory listing working. When I mount
> the service and start fuse, I see that it is trying over and over again to
> LOOKUP, OPENDIR, GETATTR, READDIR for nodeid: 1. when i try to do an ls
> within the mountpoint i get an Input/Output error.

nodeid = 1 is the root directory of your filesystem, i.e. the
mountpoint.

I would guess that whatever you are returning from lookup, getattr or
readdir is invalid.

Try hardcoding something simple for this special case (e.g. use the code
from example/hello_ll.c).


Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel

Ok, so I fixed my implementation of getattr and now it doesn't loop endlessly anymore. Now the next issue is as soon as i try to ls the mountpoint, i immediately get a I/O error. No additional debug logs are shown in the console.

unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
INIT: 7.26
flags=0x001ffffb
max_readahead=0x00020000
   INIT: 7.26
   flags=0x00009029
   max_readahead=0x00020000
   max_write=0x00020000
   max_background=0
   congestion_threshold=0
   time_gran=1
   unique: 1, success, outsize: 80
unique: 2, opcode: ACCESS (34), nodeid: 1, insize: 48, pid: 8406
   unique: 2, error: -38 (Function not implemented), outsize: 16
unique: 3, opcode: OPENDIR (27), nodeid: 1, insize: 48, pid: 2919
   unique: 3, success, outsize: 32
unique: 4, opcode: LOOKUP (1), nodeid: 1, insize: 45, pid: 30087
unique: 5, opcode: GETATTR (3), nodeid: 1, insize: 56, pid: 2919
   unique: 4, error: -2 (No such file or directory), outsize: 16
unique: 6, opcode: LOOKUP (1), nodeid: 1, insize: 57, pid: 30088
   unique: 5, success, outsize: 120
unique: 7, opcode: RELEASEDIR (29), nodeid: 1, insize: 64, pid: 0
   unique: 7, success, outsize: 16
   unique: 6, error: -2 (No such file or directory), outsize: 16
unique: 8, opcode: LOOKUP (1), nodeid: 1, insize: 52, pid: 30089
   unique: 8, error: -2 (No such file or directory), outsize: 16
unique: 9, opcode: LOOKUP (1), nodeid: 1, insize: 47, pid: 8406
   unique: 9, error: -2 (No such file or directory), outsize: 16

Any other pointers to where i should be looking? I can send the contents of the various functions if that might help.

Thanks again,
Jason


Disregard this. I figured out my issue. One of the directory entries I was trying to return in readdir had a empty string for the name, which makes complete sense. Can't reference a file/dir that doesn't have a name. Thanks for your help.

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Low-level API, stuck in loop node id: 1

Nikolaus Rath
In reply to this post by Jason Miesionczek
> Ok, so I fixed my implementation of getattr and now it doesn't loop
> endlessly anymore. Now the next issue is as soon as i try to ls the
> mountpoint, i immediately get a I/O error. No additional debug logs
> are shown in the console.
>
> unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
> INIT: 7.26
> flags=0x001ffffb
> max_readahead=0x00020000
>    INIT: 7.26
>    flags=0x00009029
>    max_readahead=0x00020000
>    max_write=0x00020000
>    max_background=0
>    congestion_threshold=0
>    time_gran=1
>    unique: 1, success, outsize: 80
> unique: 2, opcode: ACCESS (34), nodeid: 1, insize: 48, pid: 8406
>    unique: 2, error: -38 (Function not implemented), outsize: 16
> unique: 3, opcode: OPENDIR (27), nodeid: 1, insize: 48, pid: 2919
>    unique: 3, success, outsize: 32
> unique: 4, opcode: LOOKUP (1), nodeid: 1, insize: 45, pid: 30087
> unique: 5, opcode: GETATTR (3), nodeid: 1, insize: 56, pid: 2919
>    unique: 4, error: -2 (No such file or directory), outsize: 16

This looks wrong. It seems as if you're filesystem reported a directory
entry, but a subsequent lookup resulted in -ENOENT.

> Any other pointers to where i should be looking? I can send the
> contents of the various functions if that might help.

Well, that depends on the clarity of your code and how big it is. Can't
hurt to post a link...


Best,
-Nikolaus

--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Low-level API, stuck in loop node id: 1

Nikolaus Rath
In reply to this post by Jason Miesionczek
On Jul 26 2017, Jason Miesionczek <[hidden email]> wrote:

> On Wed, Jul 26, 2017 at 4:59 AM, Nikolaus Rath <[hidden email]> wrote:
>
>> On Jul 25 2017, Jason Miesionczek <jmiesionczek-
>> [hidden email]> wrote:
>> > Hi,
>> >
>> > So I am working on a filesystem that interacts with a file-sharing web
>> > service. I am trying to get a basic directory listing working. When I
>> mount
>> > the service and start fuse, I see that it is trying over and over again
>> to
>> > LOOKUP, OPENDIR, GETATTR, READDIR for nodeid: 1. when i try to do an ls
>> > within the mountpoint i get an Input/Output error.
>>
>> nodeid = 1 is the root directory of your filesystem, i.e. the
>> mountpoint.
>>
>> I would guess that whatever you are returning from lookup, getattr or
>> readdir is invalid.
>>
>> Try hardcoding something simple for this special case (e.g. use the code
>> from example/hello_ll.c).
>
> Ok, so I fixed my implementation of getattr and now it doesn't loop
> endlessly anymore.

For the benefit of future readers (and to maybe give me a better idea
of the other problem): what was wrong, and how did you fix it?


Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Low-level API, stuck in loop node id: 1

Jason Miesionczek


On Thu, Jul 27, 2017 at 2:24 PM, Nikolaus Rath <[hidden email]> wrote:
On Jul 26 2017, Jason Miesionczek <[hidden email]> wrote:
> On Wed, Jul 26, 2017 at 4:59 AM, Nikolaus Rath <[hidden email]> wrote:
>
>> On Jul 25 2017, Jason Miesionczek <jmiesionczek-
>> [hidden email]> wrote:
>> > Hi,
>> >
>> > So I am working on a filesystem that interacts with a file-sharing web
>> > service. I am trying to get a basic directory listing working. When I
>> mount
>> > the service and start fuse, I see that it is trying over and over again
>> to
>> > LOOKUP, OPENDIR, GETATTR, READDIR for nodeid: 1. when i try to do an ls
>> > within the mountpoint i get an Input/Output error.
>>
>> nodeid = 1 is the root directory of your filesystem, i.e. the
>> mountpoint.
>>
>> I would guess that whatever you are returning from lookup, getattr or
>> readdir is invalid.
>>
>> Try hardcoding something simple for this special case (e.g. use the code
>> from example/hello_ll.c).
>
> Ok, so I fixed my implementation of getattr and now it doesn't loop
> endlessly anymore.

For the benefit of future readers (and to maybe give me a better idea
of the other problem): what was wrong, and how did you fix it?


Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel

Well, what I perceived to be an endless loop, was perhaps the system just continually looking up files and reading directories due to very short timeouts being returned in the lookup function for the fuse_entry_param.attr_timeout and .entry_timeout. Setting those to higer numbers slowed down the 'looping', which made sense to me.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Low-level API, stuck in loop node id: 1

Jason Miesionczek


On Thu, Jul 27, 2017 at 2:32 PM, Jason Miesionczek <[hidden email]> wrote:


On Thu, Jul 27, 2017 at 2:24 PM, Nikolaus Rath <[hidden email]> wrote:
On Jul 26 2017, Jason Miesionczek <[hidden email]> wrote:
> On Wed, Jul 26, 2017 at 4:59 AM, Nikolaus Rath <[hidden email]> wrote:
>
>> On Jul 25 2017, Jason Miesionczek <jmiesionczek-
>> [hidden email]> wrote:
>> > Hi,
>> >
>> > So I am working on a filesystem that interacts with a file-sharing web
>> > service. I am trying to get a basic directory listing working. When I
>> mount
>> > the service and start fuse, I see that it is trying over and over again
>> to
>> > LOOKUP, OPENDIR, GETATTR, READDIR for nodeid: 1. when i try to do an ls
>> > within the mountpoint i get an Input/Output error.
>>
>> nodeid = 1 is the root directory of your filesystem, i.e. the
>> mountpoint.
>>
>> I would guess that whatever you are returning from lookup, getattr or
>> readdir is invalid.
>>
>> Try hardcoding something simple for this special case (e.g. use the code
>> from example/hello_ll.c).
>
> Ok, so I fixed my implementation of getattr and now it doesn't loop
> endlessly anymore.

For the benefit of future readers (and to maybe give me a better idea
of the other problem): what was wrong, and how did you fix it?


Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel

Well, what I perceived to be an endless loop, was perhaps the system just continually looking up files and reading directories due to very short timeouts being returned in the lookup function for the fuse_entry_param.attr_timeout and .entry_timeout. Setting those to higer numbers slowed down the 'looping', which made sense to me.


But now that i've said that, is it normal for FUSE to be constantly READDIRing node id: 1?

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Low-level API, stuck in loop node id: 1

Michael Theall-2
Hi Jason,

It might help if you can see what process (using the PID) is issuing the READDIR. I once had an issue where mlocate/updatedb kept READDIRing my entire filesystem once per day, which would take several hours due to having hundreds of millions of files. READDIRPLUS helped some but ultimately we just recommended disabling mlocate/updatedb from reading FUSE filesystems or specific mount points.

Regards,
Michael Theall

On Thu, Jul 27, 2017 at 1:52 PM Jason Miesionczek <[hidden email]> wrote:


On Thu, Jul 27, 2017 at 2:32 PM, Jason Miesionczek <[hidden email]> wrote:


On Thu, Jul 27, 2017 at 2:24 PM, Nikolaus Rath <[hidden email]> wrote:
On Jul 26 2017, Jason Miesionczek <[hidden email]> wrote:
> On Wed, Jul 26, 2017 at 4:59 AM, Nikolaus Rath <[hidden email]> wrote:
>
>> On Jul 25 2017, Jason Miesionczek <jmiesionczek-
>> [hidden email]> wrote:
>> > Hi,
>> >
>> > So I am working on a filesystem that interacts with a file-sharing web
>> > service. I am trying to get a basic directory listing working. When I
>> mount
>> > the service and start fuse, I see that it is trying over and over again
>> to
>> > LOOKUP, OPENDIR, GETATTR, READDIR for nodeid: 1. when i try to do an ls
>> > within the mountpoint i get an Input/Output error.
>>
>> nodeid = 1 is the root directory of your filesystem, i.e. the
>> mountpoint.
>>
>> I would guess that whatever you are returning from lookup, getattr or
>> readdir is invalid.
>>
>> Try hardcoding something simple for this special case (e.g. use the code
>> from example/hello_ll.c).
>
> Ok, so I fixed my implementation of getattr and now it doesn't loop
> endlessly anymore.

For the benefit of future readers (and to maybe give me a better idea
of the other problem): what was wrong, and how did you fix it?


Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel

Well, what I perceived to be an endless loop, was perhaps the system just continually looking up files and reading directories due to very short timeouts being returned in the lookup function for the fuse_entry_param.attr_timeout and .entry_timeout. Setting those to higer numbers slowed down the 'looping', which made sense to me.


But now that i've said that, is it normal for FUSE to be constantly READDIRing node id: 1?
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Low-level API, stuck in loop node id: 1

Nikolaus Rath
In reply to this post by Jason Miesionczek
On Jul 27 2017, Jason Miesionczek <[hidden email]> wrote:

>> > Ok, so I fixed my implementation of getattr and now it doesn't loop
>> > endlessly anymore.
>>
>> For the benefit of future readers (and to maybe give me a better idea
>> of the other problem): what was wrong, and how did you fix it?
>
> Well, what I perceived to be an endless loop, was perhaps the system just
> continually looking up files and reading directories due to very short
> timeouts being returned in the lookup function for the
> fuse_entry_param.attr_timeout and .entry_timeout. Setting those to higer
> numbers slowed down the 'looping', which made sense to me.

Unless you have an application running that continually looks up files
on your file system, this should not happen. In other words, this change
is unlikely to have fixed your problem.

Best,
-Nikolaus

--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Low-level API, stuck in loop node id: 1

Nikolaus Rath
In reply to this post by Jason Miesionczek
On Jul 27 2017, Jason Miesionczek <[hidden email]> wrote:
> But now that i've said that, is it normal for FUSE to be constantly
> READDIRing node id: 1?

Not unless you have a process running that constantly calls readdir() on
the mountpoint.

Best,
-Nikolaus

--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Low-level API, stuck in loop node id: 1

Jason Miesionczek
Yeah that's exactly what was happening. GNOME has a volume monitor service running that was constantly reading the fuse mount.

On Fri, Jul 28, 2017 at 9:51 AM, Nikolaus Rath <[hidden email]> wrote:
On Jul 27 2017, Jason Miesionczek <[hidden email]> wrote:
> But now that i've said that, is it normal for FUSE to be constantly
> READDIRing node id: 1?

Not unless you have a process running that constantly calls readdir() on
the mountpoint.

Best,
-Nikolaus

--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Loading...