Discussion:
Hang on single threaded loop
(too old to reply)
j***@gmail.com
2009-10-20 23:37:44 UTC
Permalink
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
2009-10-21 02:44:17 UTC
Permalink
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
2009-10-22 15:09:24 UTC
Permalink
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
2009-10-22 15:18:05 UTC
Permalink
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
2009-10-22 16:18:40 UTC
Permalink
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
2009-11-05 13:12:06 UTC
Permalink
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

Continue reading on narkive:
Loading...