I am out of my office, so will reply to you correctly
when I get back home.
Kern
On 13-07-05 12:21 PM, Mariusz Mazur wrote:
> On Fri of July 5 2013, Kern Sibbald wrote:
>
>>> Hello,
>> I am sorry but the IBM license is not compatible with the Bacula license,
>> so it is not possible to include th
On Fri of July 5 2013, Kern Sibbald wrote:
> > Hello,
>
> I am sorry but the IBM license is not compatible with the Bacula license,
> so it is not possible to include this patch in Bacula.
I've sent two patches:
1. A general case that implements the 'IOError at EOM' option, which would
work for
Hello,
I am sorry but the IBM license is not compatible with the Bacula license,
so it is not possible to include this patch in Bacula.
I would strongly suggest that you correct the IBM driver rather than
try to make Bacula work with a driver that does not conform to Linux
standards.
Best regar
On Thu of July 4 2013, Mariusz Mazur wrote:
> Part two does ibm-specific error detection, so it's
> non-mergable. I'll send it later, maybe it'll be useful to some people.)
Attached. To actually use it, one needs to apply both patches and add the
following to sd's config:
Use MTIOCGET = No
On Thu of July 4 2013, Radosław Korzeniewski wrote:
> Maybe it will be a simpler and most efficient approach for Bacula community
> to handle this (not so broken) lin_tape different behavior then force to
> fix this driver.
Fixing the driver would be a good idea, that's for certain. Returning an
Hello,
I confirm that Bacula is not working with IBM lin_tape driver. Thanks to
Mariusz description I know the reason.
2013/7/3 Kern Sibbald
> Hello,
>
> (...)
> The standard is what is in the Linux man pages, which I think is:
>
>man st
>
>
It is a Linux SCSI Tape driver, not a lin_tape d
Hello,
I would hesitate to make any changes to Bacula, because it has been
functioning correctly now for every device I know of for 14 years. This
is particularly true of "ignoring" an I/O error status. That
doesn't mean that we couldn't consider it ...
What would be much preferable would be to
When doing a goto End Of Data operation using an fsf(1) loop, sd does a read()
on each iteration to check whether it reached EOD yet. It expects two things:
1. read() to return 0 bytes, meaning EOF.
2. read to return error ENOSPC which is, according to the code comment, what
IBM drivers tended to
