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. 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 :)
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
|
