is it me, or is tar too slow?

[yekibud]

On a P4 3GHz 512 RAM with newly installed slack 10.1 kernel 2.6.10 , I get major hangage with some batch tar-ing (e.g. 10-20 files), a la:

ls *.tar | xargs -i tar -xf \{\}
- or -
find -maxdepth 1 -name "*.tar" -exec tar -xf {} \;
- or -
what have you...

I get major mouse stuttering and can hear the load on my fans, until the process stops or I stop it. Then there's a little 'after-shock' a few seconds later, for a few seconds.

This doesn't seem right to me. Any thoughts?

[Fallen Angel]

My advice is dont use tar to pack files because it doesn't compress files. Use bzip2 or gzip instead.

[Krendoshazin]

tar archives directories so that you can compress them as a single file with gzip or otherwise, on their own they can't do this and is the reason for .tar.gz files

[yekibud]

I'm sorry - I should have been more clear: I'm 'tar -x'-ing, i.e. un-tarring.

[yekibud]

Ok, I think I've tracked this down to a DMA problem (with a little help from my friends), but getting DMA to work seems to be a bear.

LSPCI tells me my IDE controller is VT82C586A, but when I recompile my kernel for VIA82cxxx, I still get the hdparm -d1 /dev/hda error:

/dev/hda:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Operation not permitted
using_dma = 0 (off)

Found another thread related to DMA and chipset problems, which involved disabling generic IDE support and setting four different DMA options in the kernel .config, but that solution didn't work for me. Man, what a headache... what am I missing?