[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FTS not ready for a remount during traversal
From: |
Kamil Dudka |
Subject: |
Re: FTS not ready for a remount during traversal |
Date: |
Thu, 22 Oct 2009 19:19:54 +0200 |
User-agent: |
KMail/1.12.1 (Linux/2.6.29.5-191.fc11.x86_64; KDE/4.3.1; x86_64; ; ) |
On Thu October 22 2009 16:42:48 Jim Meyering wrote:
> Have you measured the performance penalty it incurs?
> I hope it is possible to do the same thing, but with less of a penalty.
>
> I'm afraid we'll have to do something like that one way or
> another. At best, the impact will be so small that we won't
> even have to provide a new "flag" to enable it.
Here are some basic metrics (/var is ext3, /mnt/archive is NFSv3):
Before patch
============
# time du -sh /var
2.8G /var
real 0m0.222s
user 0m0.038s
sys 0m0.186s
# time find /var > /dev/null
real 0m0.187s
user 0m0.068s
sys 0m0.118s
# time find /mnt/archive/fotky/ > /dev/null
real 0m0.089s
user 0m0.010s
sys 0m0.031s
After patch
===========
# time du -sh /var
2.8G /var
real 0m0.220s
user 0m0.051s
sys 0m0.169s
# time find /var > /dev/null
real 0m0.197s
user 0m0.055s
sys 0m0.142s
# time find /mnt/archive/fotky/ > /dev/null
real 0m0.090s
user 0m0.007s
sys 0m0.030s
There is no measurable performance penalty, assuming you have more files than
directories in the tree (which is IMO the common use case). I am attaching
also a filtered strace output showing the cost of the second stat call:
# strace -rve trace=openat,newfstatat -o trace.raw du -sh /var
# grep -A1 -B1 openat trace.raw | lzma -c > trace.lzma
Kamil
trace.lzma
Description: application/lzma