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.
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 :) Jim Richardson -----Original Message----- From: Alan Brown [mailto:a...@mssl.ucl.ac.uk] Sent: Tuesday, March 21, 2017, 2:18 PM To: Jim Richardson <j...@securit360.com>; Kern Sibbald <k...@sibbald.com>; bacula-users@lists.sourceforge.net Cc: Simone Caronni <negativ...@gmail.com>; Roberts, Ben <ben.robe...@gsacapital.com>; Alan Brown <a...@mssl.ucl.ac.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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
