|
Re: [Bacula-users] Configuring autochanger with SAS LTO-5 drives
2017-06-08 11:12:37
|
Subject: |
Re: [Bacula-users] Configuring autochanger with SAS LTO-5 drives |
|
From: |
Alan Brown <ajb2 AT mssl.ucl.ac DOT uk> |
|
Date: |
Thu, 8 Jun 2017 16:11:15 +0100 |
On 05/06/17 15:48, Alan Brown wrote:
IMHO: The best thing to do with LTO is use the largest block size
bacula will accept and a file size of 16GB or larger - and make sure
your (ssd) spool is large enough to avoid filling it up.
Don't forget: If you alter the block size, you MUST close off all
existing tapes and initialise/recycle new ones. Bacula doesn't mind
different block sizes on different tapes but encountering a change
partway through a reel "may give undesirable results" when reading.
Given comments about the block size, I think this should be noted:
Following up on Kern's comment about block sizes (Using BEE 8.8.3, but
should be close to the community versions) and that bacula-sd will
accept larger block sizes than the 2M in documentation.
Yes, it will accept the larger block sizes, BUT: If you set the block
size larger than 2M, bacula-sd silently truncate it to 64kB
Be warned. (Kern, perhaps you should consider this a bug, given that
'bacula-sd -t' doesn't throw an error message)
Experimentation here showed that the throughput advantage tapered off
after 512kB, but 2MB blocks means the drives are being given 72-250
writes/second instead of 1300-2500 @ 64kB, which translates to lower
overall loading on the system (interrupt loads).
There's some confusion between tape buffers, block sizes and actual
drive buffers.
LTO5 drives contain at least 1GB of ram which is used to buffer what's
coming from the computer and feed the internal compression/encryption
engines, then buffer the output of those sections to the actual tape itself.
Block sizes are about what's written to tape.
Tape buffering in this context is the data sitting between the "written
to tape" phase and "confirmed OK" phase (which happens as the written
data is readback inflight from the adjacent read head. If a LTO drive
says something has been written, it _HAS_ been written and verified.)
One of the reasons raised by Baculasystems for not allowing larger block
sizes is the time burned when verification fails and the block has to be
re-recorded, but the reality is that would still only be 1/10-1/20 of
one second at 140MB/s (and it's all handled internally to the drive anyway).
One gotcha is that different LTO drives actually have different maximum
block sizes. IBM FH tend to be 8MB whilst HP FH are 16MB and this may
cause problems trying to read tapes recorded on one drive, on another
one (The HH units all seem to be 8MB).
I believe a better option than manually setting (or defaulting to 64kB)
is to interrogate the drive using sg_tools or tapeinfo and set the
maximum block size based on what it reports. (ie, autotuning):
# tapeinfo -f /etc/bacula/DEVICES/drive-1-sg
Product Type: Tape Drive
Vendor ID: 'IBM '
Product ID: 'ULTRIUM-TD6 '
Revision: 'G350'
Attached Changer API: No
SerialNumber: 'F3A2930094'
MinBlock: 1
MaxBlock: 8388608
SCSI ID: 1
SCSI LUN: 0
Ready: no
# sg_read_block_limits /etc/bacula/DEVICES/MSSLYF-1-sg
Read Block Limits results:
Minimum block size: 1 byte(s)
Maximum block size: 8388608 byte(s), 8192 KB, 8 MB
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
ADSM.ORG Privacy and Data Security by https://kimlaw.us
|
