Red Hat Bugzilla – Bug 60084
DDS-3 tapes appear no longer to be compressed
Last modified: 2007-04-18 12:40:29 EDT
Description of Problem:
DDS-3 tapes under kernel-2.4.9-21 appear not to be compressed. They were in
previous releases, including 2.4.9-13. The DDS3 DAT is a 12GB native/24GB
My backup software writes several dump files onto tape in sequence. The two
partition sets I use are both within 1GB of 12GB, and fluctuate on a daily
basis. Prior to installing the current kernel, I never once ran out of space,
and I wrote as much as 26GB on some DDS3 tapes (not while doing these backups).
Now, whenever the partitions get bigger than about 12GB (according to df), the
backup errors out with:
dd: writing to `/dev/nst0': No space left on device
This is true on both partition sets. The tapes are fresh, though that shouldn't
matter. The same partitions never gave problems before, and 90+% of the data
are the same. Since compression is in hardware (if it's turned on), the same
data should fit in the same space. Much of the data is in ASCII files (email,
PS files, TeX documents, source code, etc.)
It is not clear from mt(1), st(4), sys/mtio.h, or the kernel docs how to select
the different densities/compressions for this tape in the tape driver: mt
compression and density commands do not affect the result of mt status, which is
the same as it always has been, namely:
% mt status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x25 (DDS-3).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. command-producing-data | dd of=/dev/nst0 obs=10k
Tape reaches EOF after 12GB.
Tape holds over 26GB of the same data.
The drive in question bit the dust shortly after I submitted this. While I
don't understand how the behaviors might be related, I'm closing this because I
can't say for sure that the problem was not with the drive.