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 compressed drive. 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): kernel-2.4.9-21 How Reproducible: 100% Steps to Reproduce: 1. command-producing-data | dd of=/dev/nst0 obs=10k 2. 3. Actual Results: Tape reaches EOF after 12GB. Expected Results: Tape holds over 26GB of the same data. Additional Information: --jh--
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. --jh--