Hi. On Wed, Oct 17, 2018 at 04:44:25PM +0200, Support (Jens) wrote: > Hi, > > >> we have a NAS system acting as a place to store our server's backups > >> (via rsync with link-dest). On that NAS we switched from the stable > >> kernel (4.9) to the one provided by backports (4.18) because of an > >> unrelated problem. When we do that, we see a slowdown of our backup > >> process, from the backup via rsync itself to deleting old backup > >> directories. The slowdown seems to be connected to the number of > >> files/directories as backups of systems with less files seem less > >> affected than the ones with many files. > > > > I'd complete your tests with an invocation of 'perf record/perf top' > > on NFS server side. > > The reason being - you'll be able to point out at particular > > kernel/userspace functions that are responsible for this slowdown. > > there is no NFS in play, everything was tested locally or did I > misinterpret your suggestion.
No, it was a bad wording from me. Old habit - it's not a NAS unless it has NFS, and all that. Disregard 'NFS' part. You have a host that serves a role of a fileserver that experiences a slowdown. You do tests on this host with assorted kernel versions trying to locate problematic kernel versions. Before doing these tests once more you run 'perf record' in a separate shell, and terminate 'perf record' once a test is done. Next you copy resulting 'perf.data' file for safekeeping. Rinse and repeat for each kernel/filesystem tested. Once all needed combinations of kernel/filesystem are tested once more, you use 'perf report' and 'perf annonate' to show you actual userspace/kernel functions that were in play at the time of tests. Reco
