Re: [fuse-devel] Some FUSE performance questions

[Aditya R. <adi...@gm...>]

Goswin,

Thanks for the reply. For the first issue what you said makes sense, I
should have noticed that. But for the second issue (i.e. sequential input)
note that the FUSE FS is still just passing the read calls to the native FS.
In that case, is there anything internal to FUSE that would still cause
double caching? As for memory allocations, again, could this be due to FUSE
allocating large amounts of memory internally that won't happen with the
native FS when reading a large file? The 350MB difference I'm seeing (as
pointed out in the previous post) is quite a large amount.

Thanks,

Aditya

On Tue, Dec 23, 2008 at 7:51 AM, Goswin von Brederlow <gos...@we...>wrote:

> "Aditya Rajgarhia" <adi...@gm...> writes:
>
> > Hi,
> >
> > I ran some Bonnie tests as part of a larger project, and noticed a couple
> of
> > behaviors that I cannot explain. I tested the native fs and a FUSE fs
> which
> > simply passes through each operation down to the native fs. I then
> plotted
> > the throughputs for varying file sizes (10MB - 800MB). The following are
> a
> > couple of things that confuse me.
> >
> > 1. Both native fs as well as FUSE throughputs for block output start out
> > very high and decrease until a point (say around 200MB) after which both
> > sort of converge. For the native fs, I think this is expected because for
> > small file sizes it doesn't need to write to disk, but rather, only to
> the
> > page cache. However, as far as I know, FUSE does not utilize the page
> cache
> > for writing, but just writes to disk synchronously and updates the page
> > cache. In that case, what explanation could there be for the FUSE write
> > throughput starting out high and decreasing until a point? Seems to me
> that
> > the expected throughput for block write with FUSE should simply be
> constant
> > regardless of the file size, since each write operation goes to disk
> anyway.
>
> You said the fuse filesystem just passes down the request to the
> native FS, and THAT cache just fine no matter what fuse does.
>
> > 2. For sequential input, both the native fs and FUSE start out high, and
> > then drop down suddenly at a point. I expected this, reasoning that the
> > throughput would be much higher while the file size is small enough for
> the
> > file to reside in the page cache. Presumably, the point at which the
> > throughput drops is the when the file size is too large for it to reside
> in
> > the page cache. What I find very surprising though, is that this point is
> > different for the native fs and for the FUSE fs. For the native, the
> > throughput drops after 600MB wherease for FUSE this happens at 250MB. I
> > understand that the Linux page cache behavior depends upon several
> factors
> > and parameters that can be modified via /proc but nonetheless, this is a
> > very big difference and must have a concrete reason.
> >
> > Any explanations or help for the above?
>
> Caching of fuse and the native FS leading to double the number of
> pages in cache? Memory allocations trashing the caches earlier?
>
> > Thanks,
> >
> > Aditya
>
> MfG
>         Goswin
>



-- 
(309) 750 0861
adi...@gm...