Re: [fuse-devel] FUSE readdir() performance and readdir_plus

[Feng S. <ste...@gm...>]

Well, before answer those questions, let me explain what I find today.
1. As I have already know, fuse will allocate one page for each kernel
readdir() call and then free it after the call is finished......
That's what I mean there is actually no cache for directories.
2. For the readdir case, this can get 128 entries from user-space
daemon in my test (the file name is 7 bytes long).
3. But for the readdir_plus case, this can only get 22 entries from
user-space, which is much smaller than the readdir case.
I guess that's why in HSFS, readdir_plus is slower. 22 entries for
each time might not be large enough to cause EXT3 to do a read-ahead
of directories...... And you know I'm running a single SATA drive,
without read-ahead, it will be pretty much slow......

Back to your last question, IMO, the read cache for directories is
better to be implemented in kernel, not the user-space.
a. For the reason of above #3, one page seems not enough, especially
for readdir_plus. (In NFS this should be 8 pages or something :-)
b. With more pages, allocate and free them in each call (above #1)
will be more expensive, so it's nature to keep them until the
directory is closed.
c. If you already keep them, and if you could invalidate/re-validate
them by the mtime changes, it will naturally be the read cache of
directories.
Actually NFS is doing that by the above way:
http://lxr.linux.no/linux+v3.7.1/fs/nfs/dir.c#L803

For your first question, yes I will try to do that, but since I could
only do it in my spare time. It will take time.:-(

On Wed, Jan 9, 2013 at 4:01 PM, Stef Bon <st...@gm...> wrote:
>
>
>
> 2013/1/9 Feng Shuo <ste...@gm...>
>>
>> On Tue, 2013-01-08 at 18:52 +0100, Stef Bon wrote:
>> >
>> >
>> >
>> > 2013/1/4 Feng Shuo <ste...@gm...>
>> >         Hi,
>> >
>> >         I did some readdir() performance tests on FUSE. Although the
>> >         test is done
>> >         with HSFS(my NFSv3 client :-) , I believe it might be
>> >         meaningful for many
>> >         other filesystems and also the FUSE framework.
>> >
>> >         7.2 The "ls -l" performance is 116.848s/106.037s. The second
>> >         "ls -l" is
>> >         slow simply because FUSE doesn't have read cache for
>> >         directory, but the
>> >         first "ls -l" is still much slower than without the
>> >         readdir_plus.
>> >
>> >
>> > What do you mean with read cache for directory?
>> Yes.
>
>
> Uhm, I mean: what do you mean with a read cache for directories?
>
>
>>
>> >
>> > I've got some filesystems with a readdir cache, ie it's possible to
>> > get the contents of a directory with contacting the backend. This
>> > maybe oudated (like any cache) but with the help of inotify (on Linux)
>> > this cache is uptodate.
>> Actually this could also be done by the mtime of the directory inode.
>> The patch set I sent out is based on a mtime patch which is in kernel
>> but not in FUSE. I'm planning to extend that patch to support directory.
>> >
>
>
> So if I understand you correctly you want to add a patch to add a directory
> cache? High level or low?
>
> Stef



-- 
Feng Shuo
Tel: (86)10-59851155-2116
Fax: (86)10-59851155-2008
Tianjin Zhongke Blue Whale Information Technologies Co., Ltd
10th Floor, Tower A, The GATE building, No. 19 Zhong-guan-cun Avenue
Haidian District, Beijing, China
Postcode 100080