Re: backup compress on the fly

[Alvin Oga <aoga@mail.Linux-Consulting.com>]

On Mon, 3 Oct 2005, Mike McCarty wrote:

> > most "large capacity" drives uses ECC which does support error correction
> > at least in the firmware and tape controllers to read the data
> > off the tape ..
> 
> So has every hard disc. But we still get disc errors, don't we?

but nobody said ecc will fix/prevent disk error ...

ecc can only fix certain error conditions

	- detect and fix 1 bit error
	- detect and fix 2 bit error
	- detect 3 bit errors

	or some silly sequences depending on the number of bits
	in each of the ecc field and what the original data
	is that it is trying to detect and fix

any othe eerror ... retry a few times and than flag the sector
was whacky and tell the os "help"
	- a smart disk controller will than rewrite that 
	sector in a new location on disk when its told
	by the os to write it someplace else
 
> > there's an asumption that you only have 1 compressed file
> > on the tape
> 
> If you read what I wrote carefully, you'll see that I stated that "if
> the whole image on tape is a compressed one" as opposed to "if the
> image on tape contains compressed files". In this particular thread,
> the context specifically mentioned as a possibility using tar with
> the "z" compression option specified, which results in a single tar
> image which is then compressed, or possibly piping the output from
> cpio into gzip.

like i said.. there can be 2 or more *.tgz files  .. each
appended after the other previous one ... 
and each of those *.tgz can have other *.tgz files inside

	write-mon-backup.tgz
	write-tue-backup.tgz which is appended after monday
 	write-wed-backup.tgz which is appended after tue
	....

	if one day's backup is bad ... so what.. the other
	files ( sectors on the tape ) are still readable

c ya
alvin