On 03/31/2017 10:27 PM, Jim Richardson wrote:
> Alan,
>
> I certainly understand what you are saying.  My days of coding full time are 
> long over.  I am just a guy trying to get a good opensource community 
> supported solution in place.  Kern will certainly have more pull then I will.
>
> Kern can you give us the official line on lin_tape support?
I am pretty well booked until the end of the year, mostly backporting 
Bacula Enterprise to the community and preparing to implement Aligned 
volumes and then the Cloud SD plugins for the community.

After that, I am not 100% sure what I will be doing, but high on my list 
is implementing Aligned volumes for tapes (actually VTLs).

The best bet for getting new tape drivers is to convince Bacula Systems 
that it is important.  At the moment, it is not on the roadmap and 
hardly on the radar screen.  I am sure of that because I define (with 
agreement of the major players) the Bacula Systems Roadmap.

By the way, if you use the default Tape Device resource, Bacula will not 
read to find the end of the tape data, it will do a single ioctl 
function, and if the driver knows how to get there fast it will do it.

Best regards,
Kern

>
> Jim Richardson
>
> -----Original Message-----
> From: Alan Brown [mailto:ajb2 AT mssl.ucl.ac DOT uk]
> Sent: Friday, March 31, 2017 3:08 PM
> To: bacula-users AT lists.sourceforge DOT net
> Subject: Re: [Bacula-users] Dell TL1000 IBM3850-HH7
>
> On 30/03/17 10:20, Kern Sibbald wrote:
>> Hello Jim,
>>
>> Thanks for the feeback.  See below ...
>>
>>
>> On 03/30/2017 02:13 AM, Jim Richardson wrote:
>>> Team,
>>>
>>> I have an update on my progress.  With the deadline for our new
>>> environment looming I started writing bash scripts to process the
>>> tape jobs as I mentioned before.  I started to receive strange
>>> errors; the tape wouldn't always start after loading. By that I mean
>>> I would receive an EIO over and over again until it woke up.  Then
>>> occasionally it would get an EIO when the tape finished, well,
>>> anything - writing, reading, rewinding, etc.  I started researching
>>> errors and Kern's last comments about MTSETDRVBUFFER, MT_ST_SYSV, and
>>> MT_ST_ASYNC_WRITES.  What I found may be the issue.  I have been
>>> using a RAID controller - a PERC H810 out of the back of a chained
>>> Dell MD1220.  I found a post explaining that the only supported
>>> configuration for the Dell TL1000 & IBM 3850 uses a plain (non-raid)
>>> SAS HBA. Users report strange errors and behaviors.  I have ordered a
>>> new 12DNW.  Once it arrives, I will retest.
>> Hmm. Your setup sounds a bit complicated, and that sometimes means
>> problems for Bacula.  Good luck with your new HBA.
>>> Alan - Sounds like butterflies, roses, and sunshine.
> Indeed, however we're going to have to change soon anyway - support for 
> changers is altering - with the new "ch" driver and the existing "st"
> driver hasn't been touched in over 12 years.
>
>
> I've raised a ticket with Bacula Systems about supporting the IBM
> Lin_tape driver and pointed them to the IBM Tape Drive Programming
> manual -
> https://www-945.ibm.com/support/fixcentral/swg/selectFixes?parent=Tape+drivers+and+software&product=ibm/Storage_Tape/Tape+device+drivers&release=1.0&platform=Linux&function=all#Others
>
> There are some interesting extensions in LTO5 onwards which should make
> life easier for positioning, etc.
> (The 'append open' command being one of the more useful commands which
> appears to be available for all versions of LTO.)
>
>
> As for what's currently tripping up Bacula, Section 4 (linux) says:
>
> If the read function reaches end of the data on the tape, input/output
> error (EIO) is returned and ASC, ASCQ keys (obtained by request sense
> IOCTLs) indicate the end of data. IBMtape also conforms to all SCSI
> standard read operation rules, such as fixed block versus variable block
>
> The lesson there is that using "read" to seek to EOD isn't the best way
> of doing it (especially when you have 'append open', which will do it
> for you automagically)
>
> There's a lot of difference between a basic dumb tape drive and a
> servoed intelligent setup like AIT, SDLT, LTO and the other half inch
> formats which know exactly where they are on the tape at all times.
>
> Sure, you can _use_ the smart drives in dumb mode but you'll get far
> better performance if you can make use of the smart features
>
> I'm running a bunch of tests on various drives at the moment, and as
> such should be able to see how well the lin_tape driver supports non-IBM
> stuff. (As far as I can see in the source there's no test to check if a
> drive is specifically IBM or not and the code is all GPL)
>
>
>>> I learned a long time ago - because "I" can make something work - "I"
>>> will own it indefinitely.  When I tire of that, we move to a solution
>>> that everyone can make work.  Unless Bacula's Team officially
>>> supports it, I won't force it :)
> I agree, but it's in everyone's interest for Bacula to support the
> driver. (Think of it like mysql vs postgres support, etc)
>
>
>> Good philosophy -- it causes a lot less grief.
>>
>> Best regards,
>> Kern
>>
>>> Jim Richardson
>>>
>>> -----Original Message-----
>>> From: Alan Brown [mailto:ajb2 AT mssl.ucl.ac DOT uk]
>>> Sent: Tuesday, March 21, 2017, 2:18 PM
>>> To: Jim Richardson <jim AT securit360 DOT com>; Kern Sibbald
>>> <kern AT sibbald DOT com>; bacula-users AT lists.sourceforge DOT net
>>> Cc: Simone Caronni <negativo17 AT gmail DOT com>; Roberts, Ben
>>> <ben.roberts AT gsacapital DOT com>; Alan Brown <ajb2 AT mssl.ucl.ac DOT uk>
>>> Subject: Re: [Bacula-users] Dell TL1000 IBM3850-HH7
>>>
>>> On 19/03/17 17:02, Jim Richardson wrote:
>>>
>>>>      I am not interested in the IBM driver if I can get the ST to work.
>>> I can understand why, but....
>>>
>>>
>>> There would be significant advantage in using the IBMtape driver over
>>> the generic ST driver if Bacula could be modified to handle its
>>> oddity on forward/back spacing.
>>>
>>>
>>> The IBMtape driver supports multipathing to tape drives and robots
>>> (Character and Generic devices) which the linux standard ST and SG
>>> drivers don't have. For 99.9% of installations that's irrelevant, but
>>> if you have a multipathed fabric (iscsi, FC or SAS) then it provides
>>> a _major_ leap in robustness and gets rid of the issue of a single
>>> drive or changer showing up as multiple /dev/st* units
>>>
>>> The reason for this being a nuisance under ST driver is when you're
>>> using udev and pointing to the drive using /dev/tape/by-id (which is
>>> the only reliable way to get to a drive on a fabric), because on any
>>> fabric disturbance udev may repoint that symbolic link to a different
>>> /dev/nst*
>>> - at which point things start breaking badly.
>>>
>>> Remember, drives have to be unlocked by the initiator WWID that
>>> locked them and all locks are additive, so what happens is that when
>>> the secondary FC controller issues an unlock and eject command, the
>>> drive doesn't remove the lock that's been set by the primary FC
>>> controller, thern fails to eject and generates an error. The robot
>>> will then throw another error ("removal prevented") which may (or may
>>> not) require manual acknowledgement before it can access other drives
>>> and as a reult the night's backup sequence comes to a an early halt.
>>>
>>> (This is also the usual cause of "My tapes won't eject" problems in
>>> robots on SAN fabrics)
>>>
>>> The IBMtape driver also has a lot more debugging, logging and
>>> monitoring capablities than the generic ST driver - which is rather
>>> long in the tooth, to say the least.... :)
>>>
>>> As far as I've been able to determine, the IBMtape driver doesn't
>>> care if the drives it's talking to are actually IBM or HP ones
>>> (they're the only 2 LTO drive makers left now), so if Bacula could
>>> use it, the driver is a worthwhile addition to any LTO-based backup
>>> system.
>>>
>>>
>>>
>>>
>>> CONFIDENTIALITY: This email (including any attachments) may contain
>>> confidential, proprietary and privileged information, and
>>> unauthorized disclosure or use is prohibited. If you received this
>>> email in error, please notify the sender and delete this email from
>>> your system. Thank you.
>>
>


------------------------------------------------------------------------------
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