Hang on single threaded loop

[j***@gmail.com]

Hi all
I am using the fuse low level API and while testing the file system we
implemented using fuse, we found out that fuse hangs if we hit too many
reads in a short interval (say 15 reads in 10 secs). HAs anyone else
encountered it? After some debugging, I see that the "read"
in "fuse_kern_chan_receive" is what is stuck.
Any help is much appreciated.

thx

[Arun Ramachandran]

I do not think it has anything to do with the frequency of reads. What is
probably happening is that you are not sending a proper response to one of
the calls- perhaps check close and flush if you have implemented them. The
kernel is probably waiting for response. If the number is after 10 calls
that is what it is ...

-arun




-----Original Message-----
From: ***@gmail.com [mailto:***@gmail.com]
Sent: Tuesday, October 20, 2009 4:38 PM
To: fuse-***@lists.sourceforge.net
Subject: [fuse-devel] Hang on single threaded loop

Hi all
I am using the fuse low level API and while testing the file system we
implemented using fuse, we found out that fuse hangs if we hit too many
reads in a short interval (say 15 reads in 10 secs). HAs anyone else
encountered it? After some debugging, I see that the "read"
in "fuse_kern_chan_receive" is what is stuck.
Any help is much appreciated.

thx
----------------------------------------------------------------------------
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

[Goswin von Brederlow]

Post by Arun Ramachandran
I do not think it has anything to do with the frequency of reads. What is
probably happening is that you are not sending a proper response to one of
the calls- perhaps check close and flush if you have implemented them. The
kernel is probably waiting for response. If the number is after 10 calls
that is what it is ...
-arun

And I can say that it doesn't hang even after tousands of read, write,
open or close calls. You just have to answere them all as there is a
limited number of requests the kernel will do in parallel.

MfG
Goswin

[j***@gmail.com]

I was able to figure out the actual issue. It was because i was
calling "fuse_reply_err" from release only when there was an error. I didnt
know that the same call has to be made even if there is no error. Maybe the
API should be renamed to avoid confusion or add another call
called "fuse_reply_ok" for success case.

thanks

Post by Goswin von Brederlow

Post by Arun Ramachandran
I do not think it has anything to do with the frequency of reads. What

is

Post by Arun Ramachandran
probably happening is that you are not sending a proper response to one

of

Post by Arun Ramachandran
the calls- perhaps check close and flush if you have implemented them.

The

Post by Arun Ramachandran
kernel is probably waiting for response. If the number is after 10 calls
that is what it is ...
-arun

And I can say that it doesn't hang even after tousands of read, write,
open or close calls. You just have to answere them all as there is a
limited number of requests the kernel will do in parallel.
MfG
Goswin

[Goswin von Brederlow]

I was able to figure out the actual issue. It was because i was calling
"fuse_reply_err" from release only when there was an error. I didnt know that
the same call has to be made even if there is no error. Maybe the API should be
renamed to avoid confusion or add another call called "fuse_reply_ok" for
success case.

Post by j***@gmail.com
thanks

In the fuse_lowlevel.h for each callback it states what replies are
valid:
e.g.
* Release an open file
* Valid replies:
* fuse_reply_err
void (*release) (fuse_req_t req, fuse_ino_t ino,
struct fuse_file_info *fi);

and if no reply is required it will also say so:

* Initialize filesystem
* There's no reply to this function
void (*init) (void *userdata, struct fuse_conn_info *conn);

You have to follow those rules.

I'm wondering though why fuse_reply_none is not a valid reply for
e.g. release() signaling no error. Does fuse_reply_none() differ from
fuse_reply_err(ESUCCESS)?

MfG
Goswin

[Miklos Szeredi]

Post by Goswin von Brederlow
I'm wondering though why fuse_reply_none is not a valid reply for
e.g. release() signaling no error. Does fuse_reply_none() differ from
fuse_reply_err(ESUCCESS)?

Yes, fuse_reply_none() basically just frees the request structure,
while fuse_reply_err() will always send a reply to the kernel.

The release request is special in that it needs a reply, but actually
ignores the return value from it.

Thanks,
Miklos