On Monday 28 July 2003 20:27, Matthias Bethke wrote:
>Hi Gene,
>
>on Monday, 2003-07-28 at 16:25:00, you wrote:
>> >Hmm...I was a bit surprised about this value already, but
>> > according to both the DIP switch and mt, compression is off.
>>
>> First, mt doesn't know or report on its setting, it can only issue
>> the commands. Amtapetype has an option to check it, by doing some
>> sort of a destructive write, see man amtapetype for details.
>
>"man mt" tells me it could ("Inquire or set the compression status
>(on/off)"), and here it correctly reports the hardware setting on
> the drive.
Hmm, a simple 'mt -f /dev/nst0 compression' just returns a prompt
here. Ditto for defcompression. What version of mt-st do you have?
>> >Can amanda be told to use bzip2? This P3 is far from fully loaded
>> > with its job as a WLAN router and fileserver, and as it cannot
>> > be clocked down to save some energy, it might as well do
>> > something useful for the calories it burns :)
>>
>> Not that I know of Mathias. When bzip2 settles down to the no
>> mistakes in a year category, it might, but that hasn't happened
>> just yet, it still makes mistakes in decoding from time to time,
>> mistakes you can't get it to repeat willingly either.
>
>OK, that's a point. Seems I've just ben lucky so far.
>
>> Its also a heck of a lot (like maybe 5x?) slower than gzip when
>> both are running at maximum compression. And even gzip 'best' is
>> only of use on 1 gigahertz and up machines.
>
>Oh, I've been using it since the A4000/68040/40 days -- but then
> there were also much smaller amounts of data to crunch :) For
> incrementals I'd still consider using it.
So have I Matthias, and I thought that name looked a bit familiar!
But my 68040 lived on a PP&S card with 64 megs of ram in a 2000. And
you are right, on that 28 mhz 68040, gzip and bzip2 were similar
enough in speeds that you often had to replay the command line to see
which you used. And what do you mean, smaller data? My last drive
in that amiga was 30 gigger, pretty well filled up too.
Anyway, I base that statement pretty much on some of my experiences
unpacking kernels and patches here, I've literally had it silently
skip whole subdirs in unpacking a kernel src tarball on 20 or so
occasions over the last 5 years. There was a flurry of bz2
developement about 2 years ago, and it got better, but its not quite
'bulletproof' in that regard yet, it was only maybe 2 months ago when
I couldn't get a kernel to build, and the error was different each
time I ran the same script, which basicly blew away the srcs, and
unpacked a fresh copy of both the src and the patches. I finally
went and got the tar.gz versions of everything, it worked, and I've
not had any similar problems with the use of gzip.
>regards
> Matthias
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
|
