On Mon, 18 Jan 2010, Karel Zak wrote:
>
> Fixed.
Nope.
I have top-of-git commit being 49b1508ee28577deea76654de5c27401f99c36f8
("tests: fix RAIDs tests"), and I get very different numbers;
> Old version:
>
> $ strace -e read blkid -p floppy.img 2>&1 | \
> awk -F ' = ' 'BEGIN {x=0} /read/ && !/.*ELF/ {x += $2} END { print x }'
> 73292
>
> New version:
>
> $ strace -e read blkid -p floppy.img 2>&1 | \
> awk -F ' = ' 'BEGIN {x=0} /read/ && !/.*ELF/ {x += $2} END { print x }'
> 8192
>
> I think 8192 bytes is not so bad.
8192 would be wonderful, but it's not what I get. First off, you need to
use "strace -f", because blkid itself is just a shell script. Or if I
execture lt-blkid manually, I don't hey 8kB at all, I get 17497.
In particular:
strace -s8 -T -o trace .libs/lt-blkid /dev/sdc1
grep -v '<0.0' trace
gives
read(3, "\353<\220){'`j"..., 1024) = 1024 <1.024049>
read(3, "\0\0\0\0\0\0\0\0"..., 16384) = 16384 <2.048790>
close(3) = 0 <4.102118>
and I have _no_ idea why that close() takes so long, but I'm guessing that
it is flushing the page cache and has to wait for any read-ahead to
finish.
That is arguably a kernel problem, and I'll take a look at it. Although
disabling read-ahead in blkid is probably a good thing regardless.
However, the real problem is that you didn't fix the whole-disk case:
strace -s8 -T -o trace .libs/lt-blkid /dev/sdc
grep -v '<0.0' trace
results in
read(3, "\0\0\0\0\0\0\0\0"..., 1024) = 1024 <1.023949>
read(3, "\353<\220){'`j"..., 16384) = 16384 <2.046643>
read(3, "\0\0\0\0\0\0\0\0"..., 32768) = 32768 <4.093214>
read(3, "\0\0\0\0\0\0\0\0"..., 1024) = 1024 <8.447666>
read(3, "\0\0\0\0\0\0\0\0"..., 1377) = 1377 <0.257814>
anyway, it all is slightly improved, but the timings are still abysmal:
[root@EeePC util-linux-ng]# time misc-utils/.libs/lt-blkid /dev/sdc
real 0m15.895s
user 0m0.001s
sys 0m0.010s
and
[root@EeePC util-linux-ng]# time misc-utils/.libs/lt-blkid /dev/sdc1
/dev/sdc1: SEC_TYPE="msdos" TYPE="vfat"
real 0m7.185s
user 0m0.002s
sys 0m0.008s
> ... or I can add a test rpm package to Fedora testing repository.
> What version of Fedora are you running on the machine?
It's Fedora-12, but I can certainly test git trees and/or patches too.
Linus
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
