cannot handle too many requests simultaneously in fuse?

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

cannot handle too many requests simultaneously in fuse?

Pahome Chen
I write a program which will create 10 threads in a pool. 

Then I will let the 10 threads read the same file in the fuse which I made.

But I saw fuse only handle a few mounts of requests(maybe 1~4 requests) in debug mode.

I saw the other requests will finish open operation but don't enter in read operation.

other requests will go on executing after the before requests finished.

why? I thought fuse will handle all requests almost simultaneously.

Fuse Lib version: 2.9.7
using FUSE kernel interface version: 7.19
command option: -o allow_other -d


--
Best Regards,
pahome

------------------------------------------------------------------------------
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: cannot handle too many requests simultaneously in fuse?

Nikolaus Rath
On Jun 01 2017, Pahome Chen <[hidden email]> wrote:

> I write a program which will create 10 threads in a pool.
>
> Then I will let the 10 threads *read* the same file in the fuse which I
> made.
>
> But I saw fuse only handle a few mounts of requests(maybe 1~4 requests) in
> debug mode.
>
> I saw the other requests will finish *open* operation but don't enter in *read
> *operation.
>
> other requests will go on executing after the before requests finished.
>
> why? I thought fuse will handle all requests almost simultaneously.


It depends. From fuse_common.h:

/**
 * Indicates that the filesystem supports asynchronous read requests.
 *
 * If this capability is not requested/available, the kernel will
 * ensure that there is at most one pending read request per
 * file-handle at any time, and will attempt to order read requests by
 * increasing offset.
 *
 * This feature is enabled by default when supported by the kernel.
 */
#define FUSE_CAP_ASYNC_READ (1 << 0)


Did you enable this?


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: cannot handle too many requests simultaneously in fuse?

Pahome Chen
yes, I enabled it.
and my command option is -o allow_other -o async_read -d 

Almost situation fuse handle requests to the same file are below:
1 requests -> 5 requests -> 4 requests
2 requests -> other last requests

only the first 1 or 2 or 3 requests enter read section almostly, then other requests enter read section.

2017-06-02 1:59 GMT+08:00 Nikolaus Rath <[hidden email]>:
On Jun 01 2017, Pahome Chen <[hidden email]> wrote:
> I write a program which will create 10 threads in a pool.
>
> Then I will let the 10 threads *read* the same file in the fuse which I
> made.
>
> But I saw fuse only handle a few mounts of requests(maybe 1~4 requests) in
> debug mode.
>
> I saw the other requests will finish *open* operation but don't enter in *read
> *operation.
>
> other requests will go on executing after the before requests finished.
>
> why? I thought fuse will handle all requests almost simultaneously.


It depends. From fuse_common.h:

/**
 * Indicates that the filesystem supports asynchronous read requests.
 *
 * If this capability is not requested/available, the kernel will
 * ensure that there is at most one pending read request per
 * file-handle at any time, and will attempt to order read requests by
 * increasing offset.
 *
 * This feature is enabled by default when supported by the kernel.
 */
#define FUSE_CAP_ASYNC_READ             (1 << 0)


Did you enable this?


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



--
Best Regards,
pahome

------------------------------------------------------------------------------
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: cannot handle too many requests simultaneously in fuse?

Nikolaus Rath
On Jun 02 2017, Pahome Chen <[hidden email]> wrote:

> 2017-06-02 1:59 GMT+08:00 Nikolaus Rath <[hidden email]>:
>
>> On Jun 01 2017, Pahome Chen <[hidden email]>
>> wrote:
>> > I write a program which will create 10 threads in a pool.
>> >
>> > Then I will let the 10 threads *read* the same file in the fuse which I
>> > made.
>> >
>> > But I saw fuse only handle a few mounts of requests(maybe 1~4 requests)
>> in
>> > debug mode.
>> >
>> > I saw the other requests will finish *open* operation but don't enter in
>> *read
>> > *operation.
>> >
>> > other requests will go on executing after the before requests finished.
>> >
>> > why? I thought fuse will handle all requests almost simultaneously.
>>
>>
>> It depends. From fuse_common.h:
>>
>> /**
>>  * Indicates that the filesystem supports asynchronous read requests.
>>  *
>>  * If this capability is not requested/available, the kernel will
>>  * ensure that there is at most one pending read request per
>>  * file-handle at any time, and will attempt to order read requests by
>>  * increasing offset.
>>  *
>>  * This feature is enabled by default when supported by the kernel.
>>  */
>> #define FUSE_CAP_ASYNC_READ             (1 << 0)
>>
>>
>> Did you enable this?
>
> yes, I enabled it.
> and my command option is *-o allow_other -o async_read -d*

Do you have the same problem when you use examples/passthrough_ll?

> Almost situation fuse handle requests to the same file are below:
> 1 requests -> 5 requests -> 4 requests
> 2 requests -> other last requests
>
> only the first 1 or 2 or 3 requests enter *read *section almostly, then
> other requests enter *read *section.

Sorry, I do not understand what you're saying here.

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: cannot handle too many requests simultaneously in fuse?

Michael Theall-2
Hi Nikolaus,

Sounds like he's saying he's only getting a max of 5 concurrent (read) requests for a single file, even with async_read. If this is not a limitation of kernel fuse, I'd say it could be due to relatively small read requests from the user.

Pahome,

I would suggest you try some code that makes a large read request (like 10MB) via read(2); make sure you're not using fread(3) or iostream or whatever kind of userspace buffered I/O. Let us know if you make the same observation.

Regards,
Michael Theall

On Sat, Jun 3, 2017, 08:45 Nikolaus Rath <[hidden email]> wrote:
On Jun 02 2017, Pahome Chen <[hidden email]> wrote:
> 2017-06-02 1:59 GMT+08:00 Nikolaus Rath <[hidden email]>:
>
>> On Jun 01 2017, Pahome Chen <[hidden email]>
>> wrote:
>> > I write a program which will create 10 threads in a pool.
>> >
>> > Then I will let the 10 threads *read* the same file in the fuse which I
>> > made.
>> >
>> > But I saw fuse only handle a few mounts of requests(maybe 1~4 requests)
>> in
>> > debug mode.
>> >
>> > I saw the other requests will finish *open* operation but don't enter in
>> *read
>> > *operation.
>> >
>> > other requests will go on executing after the before requests finished.
>> >
>> > why? I thought fuse will handle all requests almost simultaneously.
>>
>>
>> It depends. From fuse_common.h:
>>
>> /**
>>  * Indicates that the filesystem supports asynchronous read requests.
>>  *
>>  * If this capability is not requested/available, the kernel will
>>  * ensure that there is at most one pending read request per
>>  * file-handle at any time, and will attempt to order read requests by
>>  * increasing offset.
>>  *
>>  * This feature is enabled by default when supported by the kernel.
>>  */
>> #define FUSE_CAP_ASYNC_READ             (1 << 0)
>>
>>
>> Did you enable this?
>
> yes, I enabled it.
> and my command option is *-o allow_other -o async_read -d*

Do you have the same problem when you use examples/passthrough_ll?

> Almost situation fuse handle requests to the same file are below:
> 1 requests -> 5 requests -> 4 requests
> 2 requests -> other last requests
>
> only the first 1 or 2 or 3 requests enter *read *section almostly, then
> other requests enter *read *section.

Sorry, I do not understand what you're saying here.

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cannot handle too many requests simultaneously in fuse?

Pahome Chen
Sounds like he's saying he's only getting a max of 5 concurrent (read) requests for a single file, even with async_read. If this is not a limitation of kernel fuse, I'd say it could be due to relatively small read requests from the user.

Yes, but the number 5 isn't a fixed number, sometimes is more than 5 and sometimes isn't. 

I would suggest you try some code that makes a large read request (like 10MB) via read(2); make sure you're not using fread(3) or iostream or whatever kind of userspace buffered I/O. Let us know if you make the same observation.

I tried from 50bytes to 2MB by read syscall, it seems the same. Always handle 1, or 2, or 3 requests first.


Let me introduce my fuse system called myfs.
It's a filesystem combined with fuse and cloud. myfs download the file when someone read the file in order to save disk space.
Now I want to simulate that 10 read requests concurrently happended.
I found that only the 1st read requests enter the read() function and other 9 requests left the open() but didn't enter read() after I checked the fuse bebug mode log.

So that make me confused with why only the 1st one handled by fuse? It's common to all filesystems?

thx

2017-06-03 23:33 GMT+08:00 Michael Theall <[hidden email]>:
Hi Nikolaus,

Sounds like he's saying he's only getting a max of 5 concurrent (read) requests for a single file, even with async_read. If this is not a limitation of kernel fuse, I'd say it could be due to relatively small read requests from the user.

Pahome,

I would suggest you try some code that makes a large read request (like 10MB) via read(2); make sure you're not using fread(3) or iostream or whatever kind of userspace buffered I/O. Let us know if you make the same observation.

Regards,
Michael Theall


On Sat, Jun 3, 2017, 08:45 Nikolaus Rath <[hidden email]> wrote:
On Jun 02 2017, Pahome Chen <[hidden email]> wrote:
> 2017-06-02 1:59 GMT+08:00 Nikolaus Rath <[hidden email]>:
>
>> On Jun 01 2017, Pahome Chen <[hidden email]>
>> wrote:
>> > I write a program which will create 10 threads in a pool.
>> >
>> > Then I will let the 10 threads *read* the same file in the fuse which I
>> > made.
>> >
>> > But I saw fuse only handle a few mounts of requests(maybe 1~4 requests)
>> in
>> > debug mode.
>> >
>> > I saw the other requests will finish *open* operation but don't enter in
>> *read
>> > *operation.
>> >
>> > other requests will go on executing after the before requests finished.
>> >
>> > why? I thought fuse will handle all requests almost simultaneously.
>>
>>
>> It depends. From fuse_common.h:
>>
>> /**
>>  * Indicates that the filesystem supports asynchronous read requests.
>>  *
>>  * If this capability is not requested/available, the kernel will
>>  * ensure that there is at most one pending read request per
>>  * file-handle at any time, and will attempt to order read requests by
>>  * increasing offset.
>>  *
>>  * This feature is enabled by default when supported by the kernel.
>>  */
>> #define FUSE_CAP_ASYNC_READ             (1 << 0)
>>
>>
>> Did you enable this?
>
> yes, I enabled it.
> and my command option is *-o allow_other -o async_read -d*

Do you have the same problem when you use examples/passthrough_ll?

> Almost situation fuse handle requests to the same file are below:
> 1 requests -> 5 requests -> 4 requests
> 2 requests -> other last requests
>
> only the first 1 or 2 or 3 requests enter *read *section almostly, then
> other requests enter *read *section.

Sorry, I do not understand what you're saying here.

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




--
Best Regards,
pahome

------------------------------------------------------------------------------
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...