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-dist AT lists.debian DOT 
> 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:
>
> [root@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 AT lists.sourceforge DOT 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:
>
> [root@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
> [root@br01 ~]#
>
> This is mt status:
>
> [root@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
> [root@br01 ~]#
>
> And this is bacula-sd configuration:
>
> [root@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
> }
> [root@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:
>
> [root@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.
> [root@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 AT lists.sourceforge DOT 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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users