Hi,
Out of this thread Bill Freeman and I got onto a side discussion of the
compression efficiency of gzip(1) vs blocksize. This led to an
experiment to take the first 2MB of /usr/doc/HOWTO/* and /bin/* and see
how well that blob compresses when broken up into blocks where each block
is gzip com
Very possible. /dev/null is essentially a device driver. Everything sent to
it goes through the kernel buffers. There are several things that can
happen, from a poorly written application that does not check things to a
poorly written library function, or a poorly written device driver.
On 2 M
This is true. I have my old dog eared C standard, but I don't care to
reread the standard.
volatile int x;
:
x = 123;
this will cause x to be flushed from the register into memory (depending
where x is defined.
x++;
<[EMAIL PROTECTED]> writes:
> Content-Type: text/plain; charset=us-ascii
Please fix this.
> I'm not
> *saying* they have infinite capacity, and I know it's ridiculous to say
> this, but I really get the feeling that these things are bottomless.
> (now watch someone prove me wrong. I'm sure
On 2 May 2002 at 14:38, Warren Mansur wrote:
> If I'm reading what you said correctly, then the volatile keyword is still
> performing as intended. I.e., if the variable must be saved after
> modification, then the compiler can't optimize out the for loop. It must
> increment the variable i until
Here's a bit of what I remember (extracted from
neurons that haven't twitched in a VERY long
time) about the "volatile" keyword; it specifies
not simply what the compiler must do with data,
but what assumptions it is allowed to make
about data. The constraints on optimization are
inescapable bu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
In a message dated: Thu, 02 May 2002 14:43:59 EDT
mike ledoux said:
> even I've been known to give people second chances on
> occassion).
I think we're going to require more proof than just your say-so ;)
Warren,
I just sent you a small test program with volatile.
Actually, compilers will try very hard to optimize loops. In a cross
platform product I am working on (for the past couple of years) we have an
assembler language loop because they can't count on the C compilers to
generate a predicta
mike ledoux writes regarding compressing a dump a chunk at a time:
> Oh, I'm not saying that it won't work, I'm sure it works just fine.
> I'm just skeptical that you get enough compression with this method to
> be worth trying to compress the data at all.
While it is almost always(*)
> Also, the volatile keyword does not tell the compiler not to optimize. It
> tells the compiler that the volatile variable must be saved after
> modification.
Thank you for the info. I stand corrected :)
> Many compilers will leave the result in a register, and may
> never even allocate mem
> IMNSHO, this idiot *and* your manager should
> both have been promptly fired for gross incompetance.
Huh? Tell us again, please, what they should have been fired for...
*
To unsubscribe from this list, send mail to [EMAIL PRO
I think the technique in use at the time was referred to as "cheating" ;^)
-Alex
Wirth's Law: Software gets slower faster than Hardware gets faster!
"On the side of the software box, in the 'System Requirements' section, it
said 'Requires Windows 95 or better'. So I installed Linux." - Anony
On Thu, 2 May 2002, Jerry Feldman wrote:
> It is virtually impossible with any kind of optimizing turned on to write a
> C code program with a loop like this.
> unsigned long
> loop(unsigned long iterations) {
> unsigned long i;
> for (i = 0; i < iterations; i++)
> ;
> retur
It is virtually impossible with any kind of optimizing turned on to write a
C code program with a loop like this.
unsigned long
loop(unsigned long iterations) {
unsigned long i;
for (i = 0; i < iterations; i++)
;
return(i);
}
Most compilers (gcc, DECC, HP C, Sun) will convert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
In a message dated: Thu, 02 May 2002 13:44:13 EDT
mike ledoux said:
>Lovely. IMNSHO, this idiot *and* your manager should both have been
>promptly fired for gross incompetance.
Well, we were all laid off
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
In a message dated: Thu, 02 May 2002 13:24:04 EDT
mike ledoux said:
>Of course, this is also going to have a negative impact on your
>compression ratio, depending on how small these 'chunks' are. I'm goin
On Thu, 2 May 2002, at 11:23am, [EMAIL PROTECTED] wrote:
> I think this is taken care of by the fact they don't actually send the
> gzip stream directly to tape. What amanda does is create "chunks" of
> backup data from the file systems you are backing up. Each "chunk" is
> separately gzipped, t
- Original Message -
From: <[EMAIL PROTECTED]>
To: "Karl J. Runge" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, May 02, 2002 2:40 PM
Subject: Re: Tape Backups
> As to capacity? I have yet to ever fill a /dev/null device. I'm not
&g
On Thu, 2 May 2002, Benjamin Scott <[EMAIL PROTECTED]> wrote:
>
> GNU tar does this. Seriously. If checks to see if the target device is
> /dev/null, and if so, skips some of the I/O operations. I discovered this
> when I wanted to exercise a disk, so I tried tar'ing it up to /dev/null, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
In a message dated: Thu, 02 May 2002 11:11:19 EDT
Benjamin Scott said:
>On Thu, 2 May 2002, at 9:50am, [EMAIL PROTECTED] wrote:
>> With amanda, sw compression is better IMO.
>
> Be aware: A single bad blo
On Thu, 2 May 2002, at 10:40am, [EMAIL PROTECTED] wrote:
> Well, usually they come included for the price of your OS. However, I
> recently discovered that MS OSes do not *have* this device. I believe, as
> with everything in MS land, it's an added cost for such a device.
Actually, each proce
On Thu, 2 May 2002, at 9:40am, Alex Hewitt USG wrote:
> Imagine if the OS were smart enough to recognize that you were copying to
> /dev/null and would simply optimize that operation out of existence!
GNU tar does this. Seriously. If checks to see if the target device is
/dev/null, and if so,
On Thu, 2 May 2002, at 9:50am, [EMAIL PROTECTED] wrote:
> With amanda, sw compression is better IMO.
Be aware: A single bad block on the tape can corrupt the gzip data stream,
rendering the rest of the backup unusable. gzip does *not* recover well
from errors.
--
Ben Scott <[EMAIL PROTECTED]
Imagine if the OS were smart enough to recognize that you were copying to
/dev/null and would simply optimize that operation out of existence! Now *that*
would be fast.
Years ago 'C' compiler writers noticed that folks were attempting to benchmark
the program that came out of their compiler by ru
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
In a message dated: Thu, 02 May 2002 07:33:09 PDT
"Karl J. Runge" said:
>On Thu, 02 May 2002, [EMAIL PROTECTED] wrote:
>
>How much does each /dev/null cost? Is there a limit to how much one can hold?
Wel
On Thu, 02 May 2002, [EMAIL PROTECTED] wrote:
How much does each /dev/null cost? Is there a limit to how much one can hold?
> Btw, I forgot to mention, if you *really* want to save money and time,
> it is most efficient to use /dev/null for your back up device. Even
> though it's a device tec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
In a message dated: 02 May 2002 10:27:27 EDT
"Kenneth E. Lussier" said:
>But that's where I store all of the e-mails that I get from our finance
>department. Wouldn't that automatically corrupt the backups
On Thu, 2002-05-02 at 10:23, [EMAIL PROTECTED] wrote:
>
> Btw, I forgot to mention, if you *really* want to save money and time,
> it is most efficient to use /dev/null for your back up device. Even
> though it's a device technology dating back over 30 years at this
> point, it somehow still h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
In a message dated: Thu, 02 May 2002 09:59:23 EDT
Bayard Coolidge USG said:
> Backups are useless unless you can make efficient use of them.
Btw, I forgot to mention, if you *really* want to save money an
To augment Paul Lussier's excellent post, I would hasten to add that
you should also take into consideration the ease with which you could
perform a partial (1 file) or total (all files) recovery. That, IMNSHO,
and I am not a professional sysadmin, is the proof of the pudding, and
where the real
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
In a message dated: 02 May 2002 09:26:56 EDT
"Kenneth E. Lussier" said:
>Hi All,
>
>I am in the market for a tape auto changer because I have to re-vamp my
>companies backup process. I'm having a little tr
Hi All,
I am in the market for a tape auto changer because I have to re-vamp my
companies backup process. I'm having a little trouble deciding on what
to go wit, though. It will most likely be an HP drive, but I don't know
what type to get: DDS4 vs DLT. The DDS4 changer can hold 6 tapes, with 1
d
32 matches
Mail list logo
