lkml.org 
[lkml]   [2002]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: IDE/ATAPI in 2.5
    >From: Tomas Szepe <szepe@pinerecords.com>

    >> >A Pentium 1200, eh?
    >> >More like Pentium 120 or star just doesn't cut it.
    >>
    >> star uses less CPU time than GNU tar. As GNU tar uses a proprietary
    >> archive format, I never use it if I may avoid to use it.

    >How does this relate to the test? I got the archive directly off your
    >ftp site -> the software has been dealing with exactly the same format
    >in both cases.

    Well. it took me only 8 years of repeated bug reports to make the GNU tar
    maintaners fix the worst problems so it is finally able to extract standard
    compliant tar archives ;-).

    As recent GNU tar is still unable to _list_ those tar files correctly
    (try ftp://ftp.fokus.gme.de/pub/unix/star/testscripts/gtarfail.tar
    and ftp://ftp.fokus.gme.de/pub/unix/star/testscripts/gtarfail2.tar),
    I would never trust GNU tar. A program that behaves inconsistent in
    list vs. extract mode is not what I like to use.

    The real problem of GNU tar is that is does still not create POSIX.1-1988
    compliantarchives while star is able to create POSIX.1-2001 archives for a year.
    This causes that many archives out on ftp servgers cannot be unpacked using
    compliant implementations.

    To understand the problem, please fetch a recent star distribution and use the
    contained program 'tartest' together with

    ftp://ftp.fokus.gme.de/pub/unix/star/testscripts/ustar-all-quicktest.tar

    and the instructions in:

    ftp://ftp.fokus.gme.de/pub/unix/star/testscripts/README.quicktest

    to find the POSIX deviations in GNU tar.

    >> >Athlon 1GHz:
    >>
    >> >kala@nibbler:/tmp/1$ time tar xjf rock.tar.bz2
    >> >real 3m19.703s
    >> >user 0m9.870s
    >> >sys 0m24.840s
    >>
    >> >According to top, the system was ~90% idle during the extraction.
    >> >Linux 2.4.19-rc1-ac3, reiserfs 3.6.
    >>
    >> Well, I wrote that this has been done with ext3 (I also checked ext2
    >> which is approx. the same speed.
    >> I don't have access to a reiserfs system that has not been compiled
    >> with debug and I don't like to put out false statements.

    >I honestly doubt ext3 would perform significantly worse than what I've
    >observed with reiserfs.

    Just try it, I did try it.

    >Never mind, however, the sole aim of my having tested the extraction of
    >rock.tar.bz2 was to show how easily you get to accuse people on lkml of
    >being incompetent w/o having any real support for your claims.

    It was (as I mentioned before) to show that there need to be some sort
    of high level coordination to make Linux better and address the needs of the
    future.

    >> >PS. Solaris is over 60% slower than Linux 2.2/2.4 in common fs
    >> >operations on my SMP SPARCstation 10.
    >>
    >> If you make such statements, it would help a lot of you would mention
    >> the Solaris version you are running. I am always running a recent
    >> Solaris beta kernel - you may have used an outdated version.

    >Umm, let's see if I can fish out the install media from somewhere...
    >jup, Solaris 2.6 5/98.

    So did you compare Solaris performance with a 4 year old Linux?

    Jörg

    EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
    js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
    schilling@fokus.gmd.de (work) chars I am J"org Schilling
    URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:27    [W:3.179 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site