Re: [fuse-devel] Odd kernel cache behaviour with fuse

[Miklos S. <mi...@sz...>]

On Mon, Dec 5, 2011 at 7:56 PM, Goswin von Brederlow <gos...@we...> wrote:
> Hi,
>
> I've completed my KissFS far enough to support basic operations so I did
> some benchmarkings. The code still has quite a few debug printfs() in it
> so the numbers are on the lower side. But something is odd with the
> numbers I get:
>
> mrvn@frosties:~/src/kissfs% dd if=/dev/zero of=tmp/foo bs=1M count=50 conv=notrunc
> 50+0 records in
> 50+0 records out
> 52428800 bytes (52 MB) copied, 0.705684 s, 74.3 MB/s
> mrvn@frosties:~/src/kissfs% dd if=tmp/foo of=/dev/null bs=1M
> 50+0 records in
> 50+0 records out
> 52428800 bytes (52 MB) copied, 0.358035 s, 146 MB/s
> mrvn@frosties:~/src/kissfs% dd if=tmp/foo of=/dev/null bs=1M
> 50+0 records in
> 50+0 records out
> 52428800 bytes (52 MB) copied, 0.087174 s, 601 MB/s
>
> In kiss_open() I do set:
>
>    fi->keep_cache = 1;
>
> The write speed is as expected as I'm doing a fsync() in kiss_release()
> and that is around the disk speed.
>
> The odd thing now is that the reading of the file calls kiss_read() for
> the whole file in 128k chunks. The rereading doesn't call any
> kiss_read() at all.
>
> The reread comes completly out of the kernel cache as it should be. But
> why does the reading of the file not? Why doesn't the kernel cache the
> data of the writes?

It should cache the writes.  I tried this with fusexmp_fh
-okernel_cache and it does cache the write.  You need to be careful
about what getattr() returns during the write because the cache will
be invalidated if the kernels idea of the file size doesn't match the
filesystems's.

Thanks,
Miklos