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