I apologize, I understand compression and read the FAQ and documentation. My question arises amidst earlier tape errors with this particular tape and the fact that all the other tapes become full at just over 400 billion bytes, or 400 gigs.
So, ok, all of a sudden compression is on. I think it must have been enabled when I was messing with btape trying to test the "bad" tape. If this is the case though, then I wonder why compression wasn't enabled the first time I ran btape on these exact same tapes/drive (note: on the last run of btape I terminated (killall) the btape console after it froze on me, which may explain that). I'm just going to wipe the pool and jobs and start over, after running a btape fill on this tape. Thanks for pointing that out. Nick ps. [EMAIL PROTECTED] ~]# tapeinfo -f /dev/sg2 Product Type: Tape Drive Vendor ID: 'HP ' Product ID: 'Ultrium 3-SCSI ' Revision: 'G24H' Attached Changer: No SerialNumber: 'HU10534WE1' MinBlock:1 MaxBlock:16777215 SCSI ID: 4 SCSI LUN: 0 Ready: yes BufferedMode: yes Medium Type: Not Loaded Density Code: 0x44 BlockSize: 0 DataCompEnabled: yes DataCompCapable: yes DataDeCompEnabled: yes CompType: 0x1 DeCompType: 0x1 Block Position: 22658 [EMAIL PROTECTED] ~]# On 1/25/07, John Drescher <[EMAIL PROTECTED]> wrote: > On 1/25/07, Nick Jones <[EMAIL PROTECTED]> wrote: > > I had a bad tape recently > > > > I have tried to verify if the tape is good or not, but I've run into > > another issue. > > > > It now wrote the tape fine, and didn't error out at > > Bytes=52,398,230,131. However, it wrote way more bytes that what > > will fit on the tape. It is a 400 GB LTO-3 tape. > > > > | 22 | tape7 | Full | 635,479,838,715 | 636 | > > 15,552,000 | 1 | 7 | 1 | LTO | 2007-01-25 > > 08:52:41 > > > > Can anyone explain how the drive wrote so much data, or why it *thinks* it > > did. > > > The drive has hardware data compression that saves tape space by > compressing each packet sent to the drive. Although the manufacture > will claim 2:1 (and call the tape a 800GB tape) is the norm this > number is highly dependent on your data. Remember that compressed data > does compress a second time and random data is also not compressible > but text is very compressible. > > > > BTW (dev team), Is this info in the docs or faq anywhere? I believe I > have answered this question 20 times or more .... > > John > -- Nick Jones University of Iowa Dept of Neurology Systems Analyst 319-356-0451 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
