>tar cvf - . | gzip -9 | dd of=/dev/tapes/tape0 bs=32k
I have a tool which compresses individual files in a tar archive
instead of the whole archive[1]. That one tries hard to write only in
standard 10kb blocks to emulate tar's behavior towards the drive.
I'll try in a few days (when I'm back
In article <[EMAIL PROTECTED]> you wrote:
> ... still, I've investigated on this because amverify gave me a ton of
> crc errors... (I REALLY hope that amanda uses proper blocking :)
yes, it does.
This really looks like a st problem, or kernel. Or host adapter, or :)
I have to try 2.4.x soon. Pr
On Sat, 14 Apr 2001, Marc SCHAEFER wrote:
> Now try this:
>
>cd ~archive
>mt -f /dev/tapes/tape0 rewind
>tar cvf - . | gzip -9 | dd of=/dev/tapes/tape0 bs=32k
>
> and then:
>
>mt -f /dev/tapes/tape0 rewind
>dd if=/dev/tapes/tape0 bs=32k | gzip -d | tar --compare -v -f -
>
> Th
In article <[EMAIL PROTECTED]> you wrote:
> So you make gzip use blocks of 32 kB.
no, infact it really makes it using blocks of 4k (a PIPE_SIZE is 4k), so
it is really equivalent to bs=4k. dd doesn't re-join blocks when
they are smaller then bs=, unless you specify obs=32k.
I have been playing w
On Sat, 14 Apr 2001, Geert Uytterhoeven wrote:
> Do you also mean it is illegal to use blocksize 10 kB (default tar, no gzip)
> with a tape drive??
not at all. Infact, with the default settings of the st driver, any
multiple of 512 bytes is ok. The additional dd step is just there to be
sure ev
On Sat, 14 Apr 2001, Marc SCHAEFER wrote:
> Now try this:
>
>cd ~archive
>mt -f /dev/tapes/tape0 rewind
>tar cvf - . | gzip -9 | dd of=/dev/tapes/tape0 bs=32k
>
> and then:
>
>mt -f /dev/tapes/tape0 rewind
>dd if=/dev/tapes/tape0 bs=32k | gzip -d | tar --compare -v -f -
>
>
Now try this:
cd ~archive
mt -f /dev/tapes/tape0 rewind
tar cvf - . | gzip -9 | dd of=/dev/tapes/tape0 bs=32k
and then:
mt -f /dev/tapes/tape0 rewind
dd if=/dev/tapes/tape0 bs=32k | gzip -d | tar --compare -v -f -
The above is the proper way to talk to a tape drive through gzip.
> This seems to happen on my system too but I have and IDE tape:
Seems uncurrelated. I'm trying this:
# cd ~archive; tar cvzf /dev/tapes/tape0 # using devfs on rewinding dev
(some 600MB of stuff...)
where ~archive is on a SCSI drive (ext2 fs on LVM volume if can help)
# tar tvzf /dev/tapes/ta
This seems to happen on my system too but I have and IDE tape:
Apr 3 00:00:48 www kernel: ide-tape: hdb <-> ht0: Seagate STT8000A rev 5.02
Apr 3 00:00:48 www kernel: ide-tape: hdb <-> ht0: 600KBps, 14*26kB buffer, 5850kB
pipeline, 80ms tDSC, DMA
I have managed to recover the tar archive by
I've recently installed a SDT-9000 tape drive. Running kernel 2.4.x I've
noticed the following (critical) problem:
Apparently the data are corrupted on the way to (from?) tape. I'm sure the
DAT
drive is good (worked good on NT, head clean, new cartridge). It doesn't
report
data errors. I've got
10 matches
Mail list logo
