>Anyway, effect under all those kernels/# of CPU's is as follows: I try to
>backup / (whole linux is in one partition) to another disk, file on same
>disk, or even /dev/null (it doesn't matter). It runs nicely. But when it
>comes to /usr/src/linux-2.2.0pre7 where the 2.2.0pre7 sources are, it
>slows down to a crawl. That means it backs up one of these really tiny *.c
>and *.h files there per 1 or 2 seconds. Basically, it is impossible to
>back this dir up in any reasonable time.
>
>I used tar -l as to exclude /proc and /mnt where the destination disk was
>mounted. Still, even 'tar -cvf/dev/null /usr/src' showed the exact same
>behaviour although it slowed down faster as it came faster to
>/usr/src/linux-2.2.0pre7 .
>
>During the slow down, top claims system is well over 90% percent idle,
>CPU time consumed by tar and general system time spent is virtually zero
>(1 or 2 %). Tar is not locked in an uninterruptible sleep waiting for a
>device ('D') nor is there any apparent high disk activity (it just gets
>these tiny files every few seconds).
You could try
# chown -R root: /usr/src/linux*
and check if it makes any difference.
Something similar showed up on linux-kernel some time ago:
it seems that tar finds those "strange" 1046/1046 values for uid/gid
and asks around (i.e. to NYS) for them, sleeping while waiting for an answer.
>To make things even more weird, cp -rv /usr/src /mnt works like a greased
>weasel. So, a simple filesystem/disk cache/dname cache/disk device or
>driver issue can IMHO be excluded.
cp doesn't try to resolve uid/gid into names, tar does.
So this *could* be a point for my explanation.
>Now, honestly, this is the very first time with linux I really have no
>clue what's going on. Therefore any comments and ideas are appreciated.
I just sent my idea. Maybe I am wrong...
>Michael.
>
Massimiliano Ghilardi
----------------------------------------------------------------
| I have yet to meet a person who had a bad experience of Linux. |
| Most have never had an experience. |
----------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/