Find the answer to your Linux question:
Results 1 to 5 of 5
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 | ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Apr 2005
    Location
    Sacramento, California
    Posts
    12

    is it me, or is tar too slow?


    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?

  2. #2
    Linux User
    Join Date
    Oct 2004
    Location
    Serbia&Montenegro
    Posts
    281
    My advice is dont use tar to pack files because it doesn't compress files. Use bzip2 or gzip instead.
    Linux registered user #358842
    Human knowledge belongs to the world.

  3. #3
    Linux User Krendoshazin's Avatar
    Join Date
    Feb 2005
    Location
    London, England
    Posts
    471
    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

  4. $spacer_open
    $spacer_close
  5. #4
    Just Joined!
    Join Date
    Apr 2005
    Location
    Sacramento, California
    Posts
    12
    I'm sorry - I should have been more clear: I'm 'tar -x'-ing, i.e. un-tarring.

  6. #5
    Just Joined!
    Join Date
    Apr 2005
    Location
    Sacramento, California
    Posts
    12
    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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •