Re: [Bacula-users] Configuring autochanger with SAS LTO-5 drives
2017-06-08 14:16:50
Hello,
Alain is certainly, for me, the tape expert. However, some of the
things Alan says about Bacula might need clarification, and after having
reviewed the code, some of the things I recently wrote about Bacula
block sizes are incorrect.
Here are the things I have just reviewed in the code:
- When reading blocks if a size exceeds 20M, an error message is printed.
- If you set the block size to more than 4M, Bacula will detect a
problem and print and error telling you the block size is too big and
that it is being reset to the default. This is detected when the SD is
starting, so Bacula attempts to the message and it is also sent to the
syslog. Note, in 7.9.x and greater it should also be put in the Job
output of the first Job that runs.
- There are various other errors that Bacula can detect with the block
size (eg spool size not at least 8 times the block size). In all cases,
it attempts to print an error. In most cases, these messages should at
least end up in the syslog. As mentioned above these daemon messages
will also be put in the Job output of the first job that runs.
By the way, the Enterprise 8.8.x code and the community 7.9.x code are
as Alain says pretty much the same. Enterprises 8.6.x code and the
community 7.4.x code are pretty much the same and somewhat different
from the 8.8.x code which has been heavily refactored and many bug fixes
applied (many found while testing the refactoring).
Before release the 9.0.0 official release, I will increase the maximum
block size to 20M.
Best regards,
Kern
On 08/06/2017 17:11, Alan Brown wrote:
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
------------------------------------------------------------------------------
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
|