We've been discussing the following issue with some samba team members and I've been requested to formalize this with a bug report.
We have performance test suites that we run on samba releases. We've seen a performance regression (when compared to samba 4.12) when performing a large number of getattr operations (specifically, to retrieve the last modified time).
The setup is that we create about 400,000 files and then use SMB to get the last modified time on those files at a controlled rate.
We have graphs that show the regression, but here are the number of syscalls that we see in 4.12 vs 4.17 (hopefully, this formats correctly):
Name samba 4.12 samba 4.17
syscall_asys_pread_count 1152 1152
syscall_asys_pwrite_count 832 832
syscall_chdir_count 4362 281514403
syscall_closedir_count 102 140758607
syscall_fcntl_count 3264 3264
syscall_fdopendir_count 32 140758607
syscall_fntimes_count 0 832
syscall_fstat_count 150095249 985313737
syscall_ftruncate_count 416 416
syscall_get_alloc_size_count 0 281517638
syscall_getwd_count 797 56
syscall_openat_count 0 844552242
syscall_readdir_count 1712 2746633627
syscall_realpath_count 150095079 281517622
syscall_stat_count 1050658924 844541884
syscall_telldir_count 1476 2465116381
(I don't want to break the "one bug per case" rule, but in case it's relevant to this, I'll mention in passing that we see a similar regression when running a performance suite that concentrates on directory listings, but we don't have a comparative list of syscalls for that case yet. I can file a separate case for that once we collect our data.)
thanks for logging the bugreport!
I really wonder why there's such an increase for syscalls like chdir, readdir and telldir. As dicussed, this likely requires some largish and dedicated engineering resources.
Backing up Ralph here. We really need to understand *exactly* what your performance test suite is doing in order to work on specifics.