Cool. I did not know there was such a thing. So controlling compression could happen at two different places. Right?
On 9/1/2010 7:15 PM, Rodrigo Ferraz wrote: > Problem solved! > > Steve Ellis pointed that there was a problem with my stinit command. > > As you'll all notice below (my original message/post), the first output of > stinit is identifying /dev/nst0 and /dev/nst0l as mode 0 and 1, respectively. > But this output is not correct, it's a bug in version 0.9b (which is part of > Redhat and CentOS distributions, as well as others). Stinit shows that nst0 > is mode 0, but this device is actually using mode 1 (with compression > enabled). The device I was using to run backups (/dev/nst0l), was not really > operating in mode 1 (with compression), but in mode 2 (without compression), > hence all the problem. > > Looks like the problem was filed as a bug by Debian users, but it clearly > affects other distributions. Here is the URL (thanks again to Steve): > http://www.mail-archive.com/debian-bugs-d...@lists.debian.org/msg379503.html > > After removing mt-st version 0.9b, getting version 1.1 source code (there is > no rpm package of this version for Redhat/CentOS), compiling and installing > it, then stinit started to output the correct information: > > [r...@br01 ~]# stinit -v -v > Trying to open database '/etc/stinit.def'. > Open succeeded. > > stinit, processing tape 0 > Mode 1, name '/dev/nst0' > Mode 2, name '/dev/nst0l' > Mode 3, name '/dev/nst0m' > Mode 4, name '/dev/nst0a' > > I know this is an operating system problem, but it would be helpful to have > it documented somewhere on bacula's website (maybe Wiki?) since it could be > affecting other RedHat/CentOS users. > > AFAIK mt-st 1.1 will be part of Redhat version 6. > > Cheers, > Rodrigo. > > -----Original Message----- > From: Rodrigo Ferraz > Sent: Wednesday, September 01, 2010 9:23 AM > To: bacula-users@lists.sourceforge.net > Cc: Suporte Concept Netservices > Subject: LTO-3 tape not compressing data/premature end of tape space > > Hello > > We've been facing this problem for a while and unfortunately we are still > unable to find an effective solution, so any help would be greatly > appreciated. > > The problem: bacula is only filling LTO-3 until exactly 394.38 GB and not > going any further a single byte. Looks like tape compression is not taking > place. > > Bconsole shows this error below and then keeps asking to mount another volume: > > 01-Sep 00:57 br01 JobId 546: End of medium on Volume "S002" > Bytes=423,463,799,808 Blocks=6,564,108 at 01-Sep-2010 00:57. > > This is tapeinfo output: > > [r...@br01 ~]# tapeinfo -f /dev/sg1 > Product Type: Tape Drive > Vendor ID: 'IBM ' > Product ID: 'ULTRIUM-HH3 ' > Revision: '93G7' > Attached Changer: No > SerialNumber: '1H10077966' > MinBlock:1 > MaxBlock:16777215 > SCSI ID: 6 > SCSI LUN: 0 > Ready: yes > BufferedMode: yes > Medium Type: 0x38 > Density Code: 0x44 > BlockSize: 0 > DataCompEnabled: yes > DataCompCapable: yes > DataDeCompEnabled: yes > CompType: 0x1 > DeCompType: 0x1 > BOP: yes > Block Position: 0 > [r...@br01 ~]# > > This is mt status: > > [r...@br01 ~]# mt -f /dev/nst0l status > SCSI 2 tape drive: > File number=0, block number=0, partition=0. > Tape block size 0 bytes. Density code 0x44 (no translation). > Soft error count since last status=0 > General status bits on (41010000): > BOT ONLINE IM_REP_EN > [r...@br01 ~]# > > And this is bacula-sd configuration: > > [r...@br01 ~]# cat /etc/bacula/bacula-sd.conf Director { > Name = br01 > Password = "abadede" > } > Storage { > Name = br01 > SDPort = 9103 > WorkingDirectory = "/var/lib/bacula" > Pid Directory = "/var/run" > Maximum Concurrent Jobs = 1 > } > Device { > Name = LTO-3 > Drive Index = 0 > Autochanger = no > Archive Device = /dev/nst0l > Maximum Changer Wait = 3d > AutomaticMount = yes > AlwaysOpen = yes > Media Type = LTO-3 > RemovableMedia = yes > Offline On Unmount = no > Spool Directory = /var/lib/bacula/spool > Maximum Spool Size = 35gb > RandomAccess = no > LabelMedia = yes > Hardware End of Medium = No > Fast Forward Space File = No > Two EOF = no > BSF at EOM = no > } > Messages { > Name = Standard > director = br01 = all > } > [r...@br01 ~]# > > > As you'll notice we are using the mode1 device (nst0l), with compression > enabled so that we can go further than 400 GB. As per stinit: > > [r...@br01 ~]# stinit -v -v > Trying to open database '/etc/stinit.def'. > Open succeeded. > > stinit, processing tape 0 > Mode 0, name '/dev/nst0' > Mode 1, name '/dev/nst0l' > Mode 2, name '/dev/nst0m' > Mode 3, name '/dev/nst0a' > The manufacturer is 'IBM', product is 'ULTRIUM-HH3', and revision '93G7'. > Mode 1 definition: scsi2logical=1 can-bsr=1 auto-lock=0 two-fms=0 > drive-buffering=1 buffer-writes read-ahead=1 async-writes=1 can-partitions=0 > fast-mteom=1 timeout=800 long-timeout=14400 blocksize=0 density=0x44 > compression=1 > Mode 2 definition: scsi2logical=1 can-bsr=1 auto-lock=0 two-fms=0 > drive-buffering=1 buffer-writes read-ahead=1 async-writes=1 can-partitions=0 > fast-mteom=1 timeout=800 long-timeout=14400 blocksize=0 density=0x44 > compression=0 > Mode 3 definition: scsi2logical=1 can-bsr=1 auto-lock=0 two-fms=0 > drive-buffering=1 buffer-writes read-ahead=1 async-writes=1 can-partitions=0 > fast-mteom=1 timeout=800 long-timeout=14400 blocksize=0 density=0x42 > compression=1 > Mode 4 definition: scsi2logical=1 can-bsr=1 auto-lock=0 two-fms=0 > drive-buffering=1 buffer-writes read-ahead=1 async-writes=1 can-partitions=0 > fast-mteom=1 timeout=800 long-timeout=14400 blocksize=0 density=0x40 > compression=1 > > stinit, processing tape 1 > Initialized 1 tape device. > [r...@br01 ~]# > > > Other information: > > Bacula Version: 5.0.1 (24 February 2010) > Tape: Dell PowerVault LTO3-060 (IBM Ultrium HH3) > O.S.: Vmware ESXi 4 (fully patched) and tape configured in pass-through mode > Guest O.S.: CentOS 5.5 > > Btape tests work fine, without any error. > > Thanks. > > Rodrigo Ferraz > CONCEPT NETSERVICES > www.conceptnetservices.com > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
