Bug 60084 - DDS-3 tapes appear no longer to be compressed
DDS-3 tapes appear no longer to be compressed
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-02-19 15:45 EST by Joe Harrington
Modified: 2007-04-18 12:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-19 15:46:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joe Harrington 2002-02-19 15:45:57 EST
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--
Comment 1 Joe Harrington 2002-04-04 14:17:46 EST
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--

Note You need to log in before you can comment on or make changes to this bug.