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
|