On Wed of July 3 2013, Kern Sibbald wrote:
> The problem with making changes to Bacula's low level code is that
> you have to test it on a pile of operating systems, with a pile of
> different tape drivers. I did that 10-12 years ago, and it was painful
> enough that I wouldn't like to do it again. You are, however, free to
> keep your own changed version if it works for you.
I appreciate the fact that bacula tries to do the right thing out of the box
in that is use tapes in a fast & secure way and if that fails, btape suggest a
slower but still secure way (turning off EOM and fast FSF). What I had in mind
was not changing the current behavior (or the current code paths guiding that
behavior), but adding more options for admins. Current hardware can do a bit
more than the old one. I'm quite certain I can prevent any non-bacula tape
operations on my autoloader – the thing has a webgui and user access controls,
so nobody's doing anything to the tapes unless I allow it. Having an option
"Admin Is Certain Bacula Has Monopoly On Tape Usage" (defaults to No :) that
allows me to make full use of the hardware I have, would be nice.
Especially considering that a current generation LTO 6 is 2.5T pre-encryption.
Even with LTO-5s I use, with a max file size set to 5 gigs, my backups get me
an EOF on average every 4 gigs. Trying to append to a tape that's, say, 2.5t
full (assuming I get 3t on lto-5 with 2:1 compression) will mean the tape's
going to do 625 forwards, stops and reads just to get into position for the
new data to get written. I'm not an expert, but that doesn't exactly sound
like it'd be good for the tape's longevity.
What I'm asking – should a patch exist that implements what I'm suggesting
without messing current code, meaning unless one explicitly enables a new
config option, tape handling is done fully by the old code, would you merge