Re: [PATCH] fuse: Add support for fuse stacked I/O

[Nikolaus Rath <Nikolaus-BTH8mxji4b0@public.gmane.org>]

On Jan 15 2016, Nikhilesh Reddy <reddyn-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> Our local benchmarks on embedded devices (where power and cpu usage is
> critical) show that splice doesnt help as much .. when running
> multiple cpu's results in increased power usage
>
> The below results are on a specific device model.
>
> Where IOPS is number of 4K based read or writes that could be performed each second.
>
>                                  regular         spliced         Stacked I/O
> sequencial write (MiBPS)	56.55633333	100.34445       141.7096667
> sequencial read (MiBPS)	        49.644	        60.43434        122.367
>
> random write (IOPS)	        2554.333333	4053.4545       8572
> random read (IOPS)	        977.3333333	1223.34         1432.666667
>
> The above tests were performed using a file size of 1GB

That looks convincing to me.

> Also we can called it FUSE_DELEGATED_IO if that helps :).
> I chose to call is stacked i/o since we are technically stacking the
> fuse read/writes on the ext4/fat or other filesystems.

Yeah, but "stacked" has a pretty strong association with union/overlay
file systems (as you have seen), and the feature is not at all specific
to that usecase.

For example, many FUSE file systems store data in some remote server
over the network but cache it on a local disk. The access to the cached
data would benefit from the feature under discussion, but I have a hard
time thinking of such a FUSE file system being "stacked" on the file
system that happens to hold its cache.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

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