[Lustre-discuss] lustre 2.2.0 statfs performance

Yevheniy Demchenko zheka at uvt.cz
Fri Apr 6 09:33:48 PDT 2012


On 04/06/2012 06:40 AM, Andreas Dilger wrote:
> On 2012-04-05, at 2:40 PM, Yevheniy Demchenko wrote:
>> We are experimenting with a new lustre-2.2.0 and surprisingly not
>> getting any statfs performance improvements. It's generally as poor as
>> in previous versions. Also, statahead does not seem to make any
>> difference to statfs performance.
>>
>> Simple ls -l test for a 100000 files directory was done on the node23
>> with statahead on and off:
>> -----statahead off-----
>> #time ls -l
>> real    0m52.751s
>> user    0m1.153s
>> sys     0m20.101s
>>
>> #time ls -l
>> real    0m21.280s
>> user    0m1.086s
>> sys     0m11.973s
>> All subsequent runs complete in virtually the same time (21-24s).
>>
>> -----statahead on-----
>> #time ls -l
>> real    0m43.846s
>> user    0m1.242s
>> sys     0m20.444s
>>
>> #time ls -l
>> real    0m24.000s
>> user    0m1.104s
>> sys     0m14.125s
>> All subsequent runs complete in virtually the same time (21-24s).
> It looks to me like a 25% improvement was seen - 53s to 44s for first run.  After that, the directories/inodes/locks/attributes are all in the client cache, so statahead is no longer active (no RPCs need to be sent).
>
>> #strace -r ls -l
>> ......
>>     0.000041 lstat("77193", {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
>>     0.000238 lgetxattr("77193", "security.selinux", 0x129d800, 255) =
>> -1 ENODATA (No data available)
> This is selinux trying to fetch xattrs.  A plague on selinux, IMHO, but we can't get rid of it.  The prefetching and caching of existing and negative  (i.e. non-existent) xattrs on the client is being discussed in http://bugs.whamcloud.com/browse/LU-549.
Thanks for reply, things are starting to be clearer. It seems, that
problem is not in selinux itself, but in not-caching xattrs in lustre in
general. if i understand correctly, statahead tries to read ahead file
attributes and put them in cache, so that client would not contact mds
for getting them. But if we don't cache xattrs, every tool like ls or
rsync will contact mds for every file as it tries to get acls and
selinux attributes, which can not be cached. Wouldn't it be better to
catch the case when FS is mounted with -o noacl and selinux is disabled
on the client side and immediately return EOPNOTSUPP without contacting
mds? We would be happy to trade acls and xattrs for a better statfs
performance.
>
> Cheers, Andreas
> --
> Andreas Dilger                       Whamcloud, Inc.
> Principal Lustre Engineer            http://www.whamcloud.com/
>
>
>
>
Ing. Yevheniy Demchenko
Senior Linux Administrator
UVT s.r.o. 




More information about the lustre-discuss mailing list