Re: Tar (but not cp) is incredible slow on certain dirs; request for comments/solution ideas/clues.
Dietmar Goldbeck (dietmar@telemedia.de)
Thu, 21 Jan 1999 20:30:15 +0100
On Thu, Jan 21, 1999 at 11:20:54AM +0100, Dr. Michael Weller wrote:
> Hi people,
>
> I've the following weird behaviour on a Compaq Proliant, 1Gig phys ram,
> Smart2 Compaq raid adapter with 6 disk Raid 5 array, 2 Xeon CPU's.
>
> I tried using both CPU's or only one (disabling it from the bios). I tried
> kernel 2.0.36 and 2.2.0pre7 (always with SMP compiled in (even when only 1
> CPU was used)). I also tried restricting the kernel memory to 64MB (side
> note: It appeared (!) to be a little faster with this setting, I assume
> handling/searching 1Gig of disk caches is much too slow. If it is not
> possible to speed the handling of cache memory up, maybe it is smarter to
> allow to set the kernel to use a maximum of n MB of buffer/caches memory.
>
> 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).
>
> 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.
>
> 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.
>
It might be the same problem that bit me some time ago with NIS:
Linus has uid/gid 1046 1046 or so set in the kernel tar archive.
If this doesn't match in /etc/passwd neither in NIS it causes
a NIS request for _every_ file. Seems that misses don't get
cached with Linux glibc NIS support.
I found out by running strace tar and tcpdump, and fixed it with entries
torvalds in NIS passwd and group :-)).
Does your problem persist after chown -R root:root
/usr/src/linux-2.2.0pre7 ?
Ciao
Dietmar
--
Reporter (to Mahatma Gandhi): Mr Gandhi, what do you think of Western
Civilization? Gandhi: I think it would be a good idea.
Dietmar Goldbeck, E-Mail: dietmar@telemedia.de; phone +49-5241-80-7646
-
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/