Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
Hi Andreas, we are using also LTO-5 with 2M Blocksize and without any Problems. Drives and Kernel are: Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux Medium ChangerOVERLAND NEO Series IBM ULTRIUM-TD5 IBM ULTRIUM-TD5 the btape tests fails like in your example, but backup and restore are working fine. Best regards Thomas -- [:O]###[O:] -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/20/2013 10:21 AM, Thomas wrote: Hi Andreas, we are using also LTO-5 with 2M Blocksize and without any Problems. Drives and Kernel are: Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux Medium ChangerOVERLAND NEO Series IBM ULTRIUM-TD5 IBM ULTRIUM-TD5 the btape tests fails like in your example, but backup and restore are working fine. Many thanks for the data point! When we use Bacula (not just btape) with larger block sizes (512 KB), our backups abort when bacula fails to read the tape's header block. I notice you have IBM drives. Maybe the block size limitation (for some reason or other) shows just up on HP drives? Our prior IBM LTO-4 drives also worked quite nicely with larger blocks. Best, Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlI8Ph8ACgkQk5ta2EV7DoySoACeLxGpAHyGzGP0vgY9jQkv9uRm 6NIAoJ88xM5QCXFxXPngTOS9NetsJjPz =Jum+ -END PGP SIGNATURE- -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
Original Message *Subject:* Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives? *Date:* Fri, 20 Sep 2013 14:22:55 +0200 *From:* Andreas Koch k...@esa.informatik.tu-darmstadt.de *To:* Thomas tho...@ic3s.de *CC:* bacula-users@lists.sourceforge.net Many thanks for the data point! When we use Bacula (not just btape) with larger block sizes (512 KB), our backups abort when bacula fails to read the tape's header block. I notice you have IBM drives. Maybe the block size limitation (for some reason or other) shows just up on HP drives? Our prior IBM LTO-4 drives also worked quite nicely with larger blocks. Hi, I'm using an HP MSL4048 with 1M blocks and backups are working fine. Cheers Alex -- This message is intended only for the addressee and may contain confidential information. Unless you are that person, you may not disclose its contents or use it in any way and are requested to delete the message along with any attachments and notify us immediately. Transact is operated by Integrated Financial Arrangements plc. 29 Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608 5300. (Registered office: as above; Registered in England and Wales under number: 3727592). Authorised and regulated by the Financial Conduct Authority (entered on the Financial Services Register; no. 190856). -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/20/2013 03:43 PM, Alan Brown wrote: On 20/09/13 13:22, Andreas Koch wrote: Many thanks for the data point! When we use Bacula (not just btape) with larger block sizes (512 KB), our backups abort when bacula fails to read the tape's header block. Did you attempt to mix blocksizes on the same physical tape? No. I initially tried writing with 512 KB to our existing tapes for differentials (that were written on LTO-4 drives onto the same tapes, also with 512 KB). That will not work. If you change block sizes all existing tapes holding data must be marked used and new ones labelled. That was my second attempt: Freshly labelled tapes. All tries with 512KB failed as described previously, only 128 KB succeeded. As with btape, the problem with the larger block sizes did not come up during writing, but during reading. This lead to all backups failing, since Bacula appears to read the on-tape header block before writing the actual backup. I run 2Mb block size quite happily on HP LTO5 drives and have done for a few years. They are capable of 16Mb - we are limited to 2Mb by Bacula. Hmm, curiouser and curiouser! I'll wait and see whether btape gets fixed to accept the larger block sizes and then proceed to run more tests. Many thanks for all the feedback! Best, Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlI8VUAACgkQk5ta2EV7Dox3tgCeKa3jVjtuyr5RX98yysxCD3vh bY8AoIwuGwOF18i+yMKnyn13Eu+4WmW2 =Auzt -END PGP SIGNATURE- -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
On 20/09/13 13:22, Andreas Koch wrote: Many thanks for the data point! When we use Bacula (not just btape) with larger block sizes (512 KB), our backups abort when bacula fails to read the tape's header block. Did you attempt to mix blocksizes on the same physical tape? That will not work. If you change block sizes all existing tapes holding data must be marked used and new ones labelled. I run 2Mb block size quite happily on HP LTO5 drives and have done for a few years. They are capable of 16Mb - we are limited to 2Mb by Bacula. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
it seems that bacula's limit is = 400
from src/stored/block.c :
if (block_len 400) {
Dmsg3(20, Dump block %s 0x%x blocksize too big %u\n, msg, b,
block_len);
return;
}
another limit i found is this one from the output of dmesg | grep st :
[3.695203] st0: Block limits 1 - 8388608 bytes.
[3.697814] st1: Block limits 1 - 8388608 bytes.
Am 20.09.2013 16:01, schrieb Andreas Koch:
On 09/20/2013 03:43 PM, Alan Brown wrote:
On 20/09/13 13:22, Andreas Koch wrote:
Many thanks for the data point! When we use Bacula (not just btape)
with larger block sizes (512 KB), our backups abort when bacula fails
to read the tape's header block.
Did you attempt to mix blocksizes on the same physical tape?
No. I initially tried writing with 512 KB to our existing tapes for
differentials (that were written on LTO-4 drives onto the same tapes, also
with 512 KB).
That will not work. If you change block sizes all existing tapes holding
data must be marked used and new ones labelled.
That was my second attempt: Freshly labelled tapes. All tries with 512KB
failed as described previously, only 128 KB succeeded.
As with btape, the problem with the larger block sizes did not come up
during writing, but during reading. This lead to all backups failing, since
Bacula appears to read the on-tape header block before writing the actual
backup.
I run 2Mb block size quite happily on HP LTO5 drives and have done for a
few years. They are capable of 16Mb - we are limited to 2Mb by Bacula.
Hmm, curiouser and curiouser! I'll wait and see whether btape gets fixed to
accept the larger block sizes and then proceed to run more tests.
Many thanks for all the feedback!
Best,
Andreas
--
[:O]###[O:]
Besser man könnte da langfahren wo man nicht muss, als wenn man wo langfahren
muss wo man nicht
kann.
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
I am curious to find out if I change the block size will I be able to go back and restore data from tapes that has the old block size? Thanks, URao -Original Message- From: Alan Brown [mailto:a...@mssl.ucl.ac.uk] Sent: Friday, September 20, 2013 9:44 AM To: Andreas Koch Cc: bacula-users@lists.sourceforge.net Subject: Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives? On 20/09/13 13:22, Andreas Koch wrote: Many thanks for the data point! When we use Bacula (not just btape) with larger block sizes (512 KB), our backups abort when bacula fails to read the tape's header block. Did you attempt to mix blocksizes on the same physical tape? That will not work. If you change block sizes all existing tapes holding data must be marked used and new ones labelled. I run 2Mb block size quite happily on HP LTO5 drives and have done for a few years. They are capable of 16Mb - we are limited to 2Mb by Bacula. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
On 09/20/2013 04:21 AM, Thomas wrote: Hi Andreas, we are using also LTO-5 with 2M Blocksize and without any Problems. Drives and Kernel are: Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux Medium ChangerOVERLAND NEO Series IBM ULTRIUM-TD5 IBM ULTRIUM-TD5 the btape tests fails like in your example, but backup and restore are working fine. Best regards Thomas I wonder if its just a bug in btape then. Brian- -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
On 20/09/13 15:03, Andreas Koch wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Alan, can you let me know what hardware (SAS Controller) and OS (kernel version) you use? Everything is FC connected using QLA 2430-series controllers. When linux first connects to the drives it reports the largest block size supported by the devices in dmesg and on the console. This information is also obtainable using tapeinfo: # tapeinfo -f /etc/bacula/DEVICES/CHANGER2-DRIVE6-sg Product Type: Tape Drive Vendor ID: 'HP ' Product ID: 'Ultrium 5-SCSI ' Revision: 'I57H' Attached Changer: No SerialNumber: 'HUE23108AJ' MinBlock:1 MaxBlock:16777215 ^ SCSI ID: 1 SCSI LUN: 0 Ready: yes BufferedMode: yes Medium Type: Not Loaded Density Code: 0x58 BlockSize: 0 DataCompEnabled: yes DataCompCapable: yes DataDeCompEnabled: yes CompType: 0x1 DeCompType: 0x1 Block Position: 971091 /etc/bacula/DEVICES/CHANGER2-DRIVE6-sg is just a symlink through to /dev/tape/by-id which makes it easier to debug errors. We also have some older LTO2 drives which report 16Mb support. Alan -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/19/2013 01:01 PM, Alan Brown wrote: Weighing in late on this thread Welcome! We are using 2Mb blocks with no problems. We have been using 512KB without problems on our older IBM LTO-4 drives (in a Tandberg StorageLoader). It's just the new HP LTO-5 drives (in Tandberg StorageLibraries) that have these problems (only) in Bacula. What specific drives and kernel versions are you using? Best, Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlI68J8ACgkQk5ta2EV7Dow3fgCdFnHzuA2xD+mJ5RdWB56NuJXA uE4AoKRV38B8YJrmHXHyJZNmPmmuNPE5 =ZSqz -END PGP SIGNATURE- -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
Thanks. It looks like there is still a bug. I recommend opening a bug report so that this is not lost. Best regards, Kern On 09/17/2013 08:54 PM, Andreas Koch wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/17/2013 06:42 PM, Kern Sibbald wrote: What version of Bacula (btape) are you using? Version: 5.2.12 (12 September 2012) Best regards, Andreas PS: Will run Martin's requested tape tests tomorrow. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlI4pWAACgkQk5ta2EV7Dox/jACdE9UeqiajHSfxsp+kno1Ou3fQ DxkAoKiKpaFuIKIVYNaIkl65RwloLNkB =n1Ta -END PGP SIGNATURE- -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Does the splitting problem occur if you write to the tape with dd and then read it back? e.g. something like dd if=/dev/urandom of=/tmp/largefile bs=512k count=1 mt -f /dev/nst0 rewind dd if=/tmp/largefile of=/dev/nst0 bs=512k dd if=/tmp/largefile of=/dev/nst0 bs=512k mt -f /dev/nst0 rewind dd if=/dev/nst0 of=/dev/null bs=512k gundabad ~ # dd if=/dev/urandom of=/tmp/largefile bs=512k count=1 +1 records in --- this is a bit strange +1 records out 5242567182 bytes (5.2 GB) copied, 922.047 s, 5.7 MB/s gundabad ~ # mt -f /dev/nst0 rewind gundabad ~ # dd if=/tmp/largefile of=/dev/nst0 bs=512k dd: writing `/dev/nst0': Invalid argument +1 records in +0 records out 5242355712 bytes (5.2 GB) copied, 42.9369 s, 122 MB/s gundabad ~ # dd if=/tmp/largefile of=/dev/nst0 bs=512k dd: writing `/dev/nst0': Invalid argument +1 records in +0 records out 5242355712 bytes (5.2 GB) copied, 39.66 s, 132 MB/s gundabad ~ # mt -f /dev/nst0 rewind gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k +0 records in +0 records out 5242355712 bytes (5.2 GB) copied, 38.5814 s, 136 MB/s So, except for the strangeness of the test file initially being created too short (5242567182 bytes are blocks and a leftover of 211470 bytes, could that be a urandom limitation?), the drive appears to work fine: The 5.2 GB written are read as a single 5.2 GB file (and not split, as btape would do with a blocksize of 512 KB). If you need any more tests, please let me know. Best, Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlI5o44ACgkQk5ta2EV7DoxDlgCgpy/BE7PmdgTNuV5nm7paXiRz lK4AoIXaK92+1trKgEcZlwQdB7r9RSqY =6raZ -END PGP SIGNATURE- -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
Hello,
It is my opinion, based on information from a Quantum tape
drive engineer and my own experiences with LTO-4 tapes that
you can safely use 256K block sizes. The Quantum guy
confirmed my belief that at larger block sizes you increase the
risk of tape errors. Note: this was back in the days of LTO-4 tapes,
thus it may have changed with the introduction of
LTO-5 and LTO-6 drives.
Some users are trying larger block sizes, but I have seen
many reports of excessive errors at block sizes of 512K and
up.
Best regards,
Kern
On 09/16/2013 01:15 PM, Andreas Koch wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/11/2013 04:47 PM, Brian Debelius wrote:
Hi,
If so what OS, Kernel, SCSI adapter, and LTO drive are you using?
Scientific Linux 6.4
Kernel 2.6.32-358.14.1.el6.x86_64
SAS Adapter IBM 6GB SAS HBA 90Y4579 (using the LSI mpt2 driver 16.00.01.00)
Drive is HP Ultrium 5-SCSI, firmware Z51U
What does your bacula-sd.conf look like?
Here is the relevant excerpt:
Device {
Name = LTO-5
Media Type = LTO-5
Archive Device = /dev/nst0
AutomaticMount = yes; # when device opened, read it
AlwaysOpen = yes;
RemovableMedia = yes;
RandomAccess = no;
Maximum File Size = 8g;
Minimum block size = 131072
Maximum block size = 131072
Changer Device = /dev/changer
AutoChanger = yes
Alert Command = sh -c 'smartctl -H -l error /dev/sg11'
Maximum Spool Size = 3000g
Spool Directory = /etc/bacula/spooldisk/BaculaSpool
Maximum Network Buffer Size = 65536
}
What is your drive block size set to?
No block size has been set using mt setblk/defblksize. But for the current
backup tape, the data is:
# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 32768 bytes. Density code 0x46 (LTO-4).
Soft error count since last status=0
General status bits on (4101):
BOT ONLINE IM_REP_EN
# tapeinfo -f /dev/nst0
Product Type: Tape Drive
Vendor ID: 'HP '
Product ID: 'Ultrium 5-SCSI '
Revision: 'Z51U'
Attached Changer API: No
SerialNumber: 'HU1324W3HT'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 3
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x46
BlockSize: 32768
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
BOP: yes
Block Position: 0
Partition 0 Remaining Kbytes: 799204
Partition 0 Size in Kbytes: 799204
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 0
Again, the crucial part is that dd can easily handle larger block sizes (we
tested up to 2 MB). But btape fails with anything larger than 128 KB (see
log in previous mails).
Best regards,
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlI26F4ACgkQk5ta2EV7DoxGmgCgmwz83Je2y94TDxnbn5AiVb7X
QvUAoJkJARz0uy44HKpdn1lp5lPivJGI
=wbTF
-END PGP SIGNATURE-
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Kern, the problem is not so much the risk of errors, but that btape (and correspondingly, Bacula) fails even the simplest of readback tests with block sizes above 128KB. dd works perfectly well with multi-megabyte blocks, both reading and writing. Here's the info I previously collected: btape cannot reliably handle anything larger than 128 KB (fails on reading, see below). However, when I read (using dd) the tape that btape supposedly has written _two_ files of 1 blocks each (and then fails after reading 3616 of them!), dd reads read _each_ of btape-written 1-block ``files'' as _three_ separate actual tape files (of 3616+3616+2768=1 blocks). Note that this specific test was performed with a block size of 512KB (see Device definition from bacula-sd.conf, below). So, this might actually be a Bacula-specific problem after all. We see this behavior consistently on two different HP LTO-5 drives, on two different SAS HBAs (one using mpt2sas as driver, the other one with mvsas), and using two different SAS cables. If you need additional info, please let me know how to proceed. Many thanks in advance, Andreas *** TRY BTAPE TEST, WILL FAIL ON READBACK gundabad ~ # btape -c /etc/bacula/bacula-sd.conf /dev/nst0 Tape block granularity is 1024 bytes. btape: butil.c:290 Using device: /dev/nst0 for writing. btape: btape.c:477 open device LTO-4 (/dev/nst0): OK *test === Write, rewind, and re-read test === I'm going to write 1 records and an EOF then write 1 records and an EOF, then rewind, and re-read the data to verify that it is correct. This is an *essential* feature ... btape: btape.c:1157 Wrote 1 blocks of 524188 bytes. btape: btape.c:609 Wrote 1 EOF to LTO-4 (/dev/nst0) btape: btape.c:1173 Wrote 1 blocks of 524188 bytes. btape: btape.c:609 Wrote 1 EOF to LTO-4 (/dev/nst0) btape: btape.c:1215 Rewind OK. Got EOF on tape. btape: btape.c:1233 Read block 3617 failed! ERR=Success *q btape: smartall.c:404 Orphaned buffer: btape 280 bytes at 15e55e8 from jcr.c:362 *** NOW READ BTAPE-WRITTEN TAPE USING DD gundabad ~ # mt -f /dev/nst0 rewind gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k 3616+0 records in 3616+0 records out 1895825408 bytes (1.9 GB) copied, 3.7062 s, 512 MB/s gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k 3616+0 records in 3616+0 records out 1895825408 bytes (1.9 GB) copied, 3.7542 s, 505 MB/s gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k 2768+0 records in 2768+0 records out 1451229184 bytes (1.5 GB) copied, 2.88829 s, 502 MB/s gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k 3616+0 records in 3616+0 records out 1895825408 bytes (1.9 GB) copied, 3.75554 s, 505 MB/s gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k 3616+0 records in 3616+0 records out 1895825408 bytes (1.9 GB) copied, 3.75338 s, 505 MB/s gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k 2768+0 records in 2768+0 records out 1451229184 bytes (1.5 GB) copied, 2.88846 s, 502 MB/s gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k 0+0 records in 0+0 records out 0 bytes (0 B) copied, 0.247548 s, 0.0 kB/s -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlI4XrkACgkQk5ta2EV7Dox5qQCeIAL+9E6K9w0L7gL2KIXCsRDZ mQ8AnAknUMOWpCpV8Vw2ZBMYRZ0JQ6IM =E1lA -END PGP SIGNATURE- -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
On Tue, Sep 17, 2013 at 9:53 AM, Andreas Koch k...@esa.informatik.tu-darmstadt.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Kern, the problem is not so much the risk of errors, but that btape (and correspondingly, Bacula) fails even the simplest of readback tests with block sizes above 128KB. dd works perfectly well with multi-megabyte blocks, both reading and writing. Here's the info I previously collected: btape cannot reliably handle anything larger than 128 KB (fails on reading, see below). However, when I read (using dd) the tape that btape supposedly has written _two_ files of 1 blocks each (and then fails after reading 3616 of them!), dd reads read _each_ of btape-written 1-block ``files'' as _three_ separate actual tape files (of 3616+3616+2768=1 blocks). Note that this specific test was performed with a block size of 512KB (see Device definition from bacula-sd.conf, below). So, this might actually be a Bacula-specific problem after all. We see this behavior consistently on two different HP LTO-5 drives, on two different SAS HBAs (one using mpt2sas as driver, the other one with mvsas), and using two different SAS cables. If you need additional info, please let me know how to proceed. Many thanks in advance, Andreas *** TRY BTAPE TEST, WILL FAIL ON READBACK gundabad ~ # btape -c /etc/bacula/bacula-sd.conf /dev/nst0 Tape block granularity is 1024 bytes. btape: butil.c:290 Using device: /dev/nst0 for writing. btape: btape.c:477 open device LTO-4 (/dev/nst0): OK *test === Write, rewind, and re-read test === I'm going to write 1 records and an EOF then write 1 records and an EOF, then rewind, and re-read the data to verify that it is correct. This is an *essential* feature ... btape: btape.c:1157 Wrote 1 blocks of 524188 bytes. btape: btape.c:609 Wrote 1 EOF to LTO-4 (/dev/nst0) btape: btape.c:1173 Wrote 1 blocks of 524188 bytes. btape: btape.c:609 Wrote 1 EOF to LTO-4 (/dev/nst0) btape: btape.c:1215 Rewind OK. Got EOF on tape. Hmm. Isn't 512K 524288 bytes not 524188 bytes? Could that be the problem? John -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
btape: btape.c:1157 Wrote 1 blocks of 524188 bytes. btape:
btape.c:609 Wrote 1 EOF to LTO-4 (/dev/nst0) btape: btape.c:1173 Wrote
1 blocks of 524188 bytes. btape: btape.c:609 Wrote 1 EOF to LTO-4
(/dev/nst0) btape: btape.c:1215 Rewind OK. Got EOF on tape.
Hmm. Isn't 512K 524288 bytes not 524188 bytes? Could that be the
problem?
Possibly. But see my bacula-sd.conf here, I did indeed request 524288 bytes:
Device {
Name = LTO-5
Media Type = LTO-5
Archive Device = /dev/nst0
AutomaticMount = yes; # when device opened, read it
AlwaysOpen = yes;
RemovableMedia = yes;
RandomAccess = no;
Maximum File Size = 8g;
Minimum block size = 524288
Maximum block size = 524288
Changer Device = /dev/changer
AutoChanger = yes
# AHK we want to interrogate the drive, not the changer
Alert Command = sh -c 'smartctl -H -l error /dev/sg11'
Maximum Spool Size = 3000g
Spool Directory = /etc/bacula/spooldisk/BaculaSpool
Maximum Network Buffer Size = 65536
}
I have asked myself about the missing 100 bytes, too, but assumed they might
be some Bacula-internal per-block header (haven't checked that, though).
Best,
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlI4ZFAACgkQk5ta2EV7Doy/9wCglO75ylkCSKZtHHr0VPBgOH55
REkAnikNRFZxaNx5nX20Dr7jJ4vzfBey
=nqRS
-END PGP SIGNATURE-
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
On Tue, 17 Sep 2013 16:16:52 +0200, Andreas Koch said:
btape: btape.c:1157 Wrote 1 blocks of 524188 bytes. btape:
btape.c:609 Wrote 1 EOF to LTO-4 (/dev/nst0) btape: btape.c:1173 Wrote
1 blocks of 524188 bytes. btape: btape.c:609 Wrote 1 EOF to LTO-4
(/dev/nst0) btape: btape.c:1215 Rewind OK. Got EOF on tape.
Hmm. Isn't 512K 524288 bytes not 524188 bytes? Could that be the
problem?
Possibly. But see my bacula-sd.conf here, I did indeed request 524288 bytes:
Device {
Name = LTO-5
Media Type = LTO-5
Archive Device = /dev/nst0
AutomaticMount = yes; # when device opened, read it
AlwaysOpen = yes;
RemovableMedia = yes;
RandomAccess = no;
Maximum File Size = 8g;
Minimum block size = 524288
Maximum block size = 524288
Changer Device = /dev/changer
AutoChanger = yes
# AHK we want to interrogate the drive, not the changer
Alert Command = sh -c 'smartctl -H -l error /dev/sg11'
Maximum Spool Size = 3000g
Spool Directory = /etc/bacula/spooldisk/BaculaSpool
Maximum Network Buffer Size = 65536
}
I have asked myself about the missing 100 bytes, too, but assumed they might
be some Bacula-internal per-block header (haven't checked that, though).
Yes, btape always prints 100 bytes less than the block size (for some reason
it prints the record size).
Does the splitting problem occur if you write to the tape with dd and then
read it back?
e.g. something like
dd if=/dev/urandom of=/tmp/largefile bs=512k count=1
mt -f /dev/nst0 rewind
dd if=/tmp/largefile of=/dev/nst0 bs=512k
dd if=/tmp/largefile of=/dev/nst0 bs=512k
mt -f /dev/nst0 rewind
dd if=/dev/nst0 of=/dev/null bs=512k
__Martin
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
What version of Bacula (btape) are you using? There was a logic error in btape that stopped reading after a certain number of bytes, because the first versions never expected to have a different block size. It seems to me that I fixed that long ago though. Best regards, Kern On 09/17/2013 03:53 PM, Andreas Koch wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Kern, the problem is not so much the risk of errors, but that btape (and correspondingly, Bacula) fails even the simplest of readback tests with block sizes above 128KB. dd works perfectly well with multi-megabyte blocks, both reading and writing. Here's the info I previously collected: btape cannot reliably handle anything larger than 128 KB (fails on reading, see below). However, when I read (using dd) the tape that btape supposedly has written _two_ files of 1 blocks each (and then fails after reading 3616 of them!), dd reads read _each_ of btape-written 1-block ``files'' as _three_ separate actual tape files (of 3616+3616+2768=1 blocks). Note that this specific test was performed with a block size of 512KB (see Device definition from bacula-sd.conf, below). So, this might actually be a Bacula-specific problem after all. We see this behavior consistently on two different HP LTO-5 drives, on two different SAS HBAs (one using mpt2sas as driver, the other one with mvsas), and using two different SAS cables. If you need additional info, please let me know how to proceed. Many thanks in advance, Andreas *** TRY BTAPE TEST, WILL FAIL ON READBACK gundabad ~ # btape -c /etc/bacula/bacula-sd.conf /dev/nst0 Tape block granularity is 1024 bytes. btape: butil.c:290 Using device: /dev/nst0 for writing. btape: btape.c:477 open device LTO-4 (/dev/nst0): OK *test === Write, rewind, and re-read test === I'm going to write 1 records and an EOF then write 1 records and an EOF, then rewind, and re-read the data to verify that it is correct. This is an *essential* feature ... btape: btape.c:1157 Wrote 1 blocks of 524188 bytes. btape: btape.c:609 Wrote 1 EOF to LTO-4 (/dev/nst0) btape: btape.c:1173 Wrote 1 blocks of 524188 bytes. btape: btape.c:609 Wrote 1 EOF to LTO-4 (/dev/nst0) btape: btape.c:1215 Rewind OK. Got EOF on tape. btape: btape.c:1233 Read block 3617 failed! ERR=Success *q btape: smartall.c:404 Orphaned buffer: btape 280 bytes at 15e55e8 from jcr.c:362 *** NOW READ BTAPE-WRITTEN TAPE USING DD gundabad ~ # mt -f /dev/nst0 rewind gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k 3616+0 records in 3616+0 records out 1895825408 bytes (1.9 GB) copied, 3.7062 s, 512 MB/s gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k 3616+0 records in 3616+0 records out 1895825408 bytes (1.9 GB) copied, 3.7542 s, 505 MB/s gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k 2768+0 records in 2768+0 records out 1451229184 bytes (1.5 GB) copied, 2.88829 s, 502 MB/s gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k 3616+0 records in 3616+0 records out 1895825408 bytes (1.9 GB) copied, 3.75554 s, 505 MB/s gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k 3616+0 records in 3616+0 records out 1895825408 bytes (1.9 GB) copied, 3.75338 s, 505 MB/s gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k 2768+0 records in 2768+0 records out 1451229184 bytes (1.5 GB) copied, 2.88846 s, 502 MB/s gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k 0+0 records in 0+0 records out 0 bytes (0 B) copied, 0.247548 s, 0.0 kB/s -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlI4XrkACgkQk5ta2EV7Dox5qQCeIAL+9E6K9w0L7gL2KIXCsRDZ mQ8AnAknUMOWpCpV8Vw2ZBMYRZ0JQ6IM =E1lA -END PGP SIGNATURE- -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/17/2013 06:42 PM, Kern Sibbald wrote: What version of Bacula (btape) are you using? Version: 5.2.12 (12 September 2012) Best regards, Andreas PS: Will run Martin's requested tape tests tomorrow. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlI4pWAACgkQk5ta2EV7Dox/jACdE9UeqiajHSfxsp+kno1Ou3fQ DxkAoKiKpaFuIKIVYNaIkl65RwloLNkB =n1Ta -END PGP SIGNATURE- -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/11/2013 04:47 PM, Brian Debelius wrote:
Hi,
If so what OS, Kernel, SCSI adapter, and LTO drive are you using?
Scientific Linux 6.4
Kernel 2.6.32-358.14.1.el6.x86_64
SAS Adapter IBM 6GB SAS HBA 90Y4579 (using the LSI mpt2 driver 16.00.01.00)
Drive is HP Ultrium 5-SCSI, firmware Z51U
What does your bacula-sd.conf look like?
Here is the relevant excerpt:
Device {
Name = LTO-5
Media Type = LTO-5
Archive Device = /dev/nst0
AutomaticMount = yes; # when device opened, read it
AlwaysOpen = yes;
RemovableMedia = yes;
RandomAccess = no;
Maximum File Size = 8g;
Minimum block size = 131072
Maximum block size = 131072
Changer Device = /dev/changer
AutoChanger = yes
Alert Command = sh -c 'smartctl -H -l error /dev/sg11'
Maximum Spool Size = 3000g
Spool Directory = /etc/bacula/spooldisk/BaculaSpool
Maximum Network Buffer Size = 65536
}
What is your drive block size set to?
No block size has been set using mt setblk/defblksize. But for the current
backup tape, the data is:
# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 32768 bytes. Density code 0x46 (LTO-4).
Soft error count since last status=0
General status bits on (4101):
BOT ONLINE IM_REP_EN
# tapeinfo -f /dev/nst0
Product Type: Tape Drive
Vendor ID: 'HP '
Product ID: 'Ultrium 5-SCSI '
Revision: 'Z51U'
Attached Changer API: No
SerialNumber: 'HU1324W3HT'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 3
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x46
BlockSize: 32768
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
BOP: yes
Block Position: 0
Partition 0 Remaining Kbytes: 799204
Partition 0 Size in Kbytes: 799204
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 0
Again, the crucial part is that dd can easily handle larger block sizes (we
tested up to 2 MB). But btape fails with anything larger than 128 KB (see
log in previous mails).
Best regards,
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlI26F4ACgkQk5ta2EV7DoxGmgCgmwz83Je2y94TDxnbn5AiVb7X
QvUAoJkJARz0uy44HKpdn1lp5lPivJGI
=wbTF
-END PGP SIGNATURE-
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Is anyone using 128K blocks with LTO-4 or LTO-5 drives?
Hi,
If so what OS, Kernel, SCSI adapter, and LTO drive are you using? What
does your bacula-sd.conf look like? What is your drive block size set
to? I am looking into this because of the post Andreas made (below) and
I am rebuilding my backup servers, and I have never been able to test or
use larger block sizes.
Brian-
---
Hi Andreas,
I have exactly the same problem with LTO-4 drives. I don't have an
answer, just a me too. I've ignored this for a long time just because
it worked with 128K blocks.
I am currently rebuilding a server based on CentOS 6.4,
2.6.32-358.18.1.el6.x86_64 #1 SMP Wed Aug 28 17:19:38 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux.
I just got everything compiled, and here is the output using 256K blocks.
# ./btape -c ../etc/bacula-sd.conf Tape
Tape block granularity is 1024 bytes.
btape: butil.c:290-0 Using device: Tape for writing.
btape: btape.c:477-0 open device Tape (/dev/nst0): OK
*rewind
btape: btape.c:579-0 Rewound Tape (/dev/nst0)
*test
=== Write, rewind, and re-read test ===
I'm going to write 1 records and an EOF
then write 1 records and an EOF, then rewind,
and re-read the data to verify that it is correct.
This is an *essential*feature ...
btape: btape.c:1157-0 Wrote 1 blocks of 262044 bytes.
btape: btape.c:609-0 Wrote 1 EOF to Tape (/dev/nst0)
btape: btape.c:1173-0 Wrote 1 blocks of 262044 bytes.
btape: btape.c:609-0 Wrote 1 EOF to Tape (/dev/nst0)
btape: btape.c:1215-0 Rewind OK.
Got EOF on tape.
btape: btape.c:1233-0 Read block 3617 failed! ERR=Success
*quit
On 08/21/2013 01:20 PM, Andreas Koch wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I am stumped by the behavior of an HP LTO-5 drive running on Scientific
Linux 6.4 (Kernel 2.6.32-358.14.1.el6.x86_64) and Bacula 5.2.12.
Specifically, using dd, I can read and write block sizes of 2 MB, but
btape
cannot reliably handle anything larger than 128 KB (fails on reading, see
below).
However, when I read the tape that btape supposedly has written two
files of
1 blocks each (and then fails after reading 3616 of them) using dd, I
read each of btape-written 1-block ``files'' as _three_actual tape
files (of 3616+3616+2768=1 blocks). Note that this test was performed
with a block size of 512KB (see Device definition from bacula-sd.conf,
below).
I would be grateful for any ideas on how to resolve this. With the
smaller
block sizes, the backup is noticeably slower for compressible data (e.g.,
database dumps), so I really would like to move back up to larger
block sizes.
Many thanks in advance,
Andreas Koch
gundabad ~ # btape -c /etc/bacula/bacula-sd.conf /dev/nst0
Tape block granularity is 1024 bytes.
btape: butil.c:290 Using device: /dev/nst0 for writing.
btape: btape.c:477 open device LTO-4 (/dev/nst0): OK
*test
=== Write, rewind, and re-read test ===
I'm going to write 1 records and an EOF
then write 1 records and an EOF, then rewind,
and re-read the data to verify that it is correct.
This is an *essential*feature ...
btape: btape.c:1157 Wrote 1 blocks of 524188 bytes.
btape: btape.c:609 Wrote 1 EOF to LTO-4 (/dev/nst0)
btape: btape.c:1173 Wrote 1 blocks of 524188 bytes.
btape: btape.c:609 Wrote 1 EOF to LTO-4 (/dev/nst0)
btape: btape.c:1215 Rewind OK.
Got EOF on tape.
btape: btape.c:1233 Read block 3617 failed! ERR=Success
*q
btape: smartall.c:404 Orphaned buffer: btape 280 bytes at 15e55e8 from
jcr.c:362
gundabad ~ # mt -f /dev/nst0 rewind
gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k
3616+0 records in
3616+0 records out
1895825408 bytes (1.9 GB) copied, 3.7062 s, 512 MB/s
gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k
3616+0 records in
3616+0 records out
1895825408 bytes (1.9 GB) copied, 3.7542 s, 505 MB/s
gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k
2768+0 records in
2768+0 records out
1451229184 bytes (1.5 GB) copied, 2.88829 s, 502 MB/s
gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k
3616+0 records in
3616+0 records out
1895825408 bytes (1.9 GB) copied, 3.75554 s, 505 MB/s
gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k
3616+0 records in
3616+0 records out
1895825408 bytes (1.9 GB) copied, 3.75338 s, 505 MB/s
gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k
2768+0 records in
2768+0 records out
1451229184 bytes (1.5 GB) copied, 2.88846 s, 502 MB/s
gundabad ~ # dd if=/dev/nst0 of=/dev/null bs=512k
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.247548 s, 0.0 kB/s
Device {
Name = LTO-5
Media Type = LTO-5
Archive Device = /dev/nst0
AutomaticMount = yes; # when device opened, read it
AlwaysOpen = yes;
RemovableMedia = yes;
RandomAccess = no;
Maximum File Size = 8g;
Minimum block size = 524288
Maximum block size = 524288
Changer Device = /dev/changer
AutoChanger = yes
# AHK we want to interrogate the drive, not the changer
Alert Command = sh -c 'smartctl -H -l error /dev/sg11'
Maximum Spool Size = 3000g
Spool Directory =
