Re: [Bacula-users] Dell TL1000 IBM3850-HH7
88608 SCSI ID: 1 SCSI LUN: 0 Ready: yes BufferedMode: yes Medium Type: 0x78 Density Code: 0x5c BlockSize: 0 DataCompEnabled: yes DataCompCapable: yes DataDeCompEnabled: yes CompType: 0xff DeCompType: 0xff BOP: yes Block Position: 0 Partition 0 Remaining Kbytes: -1 Partition 0 Size in Kbytes: -1 ActivePartition: 0 EarlyWarningSize: 0 NumPartitions: 0 MaxPartitions: 3 Jim Richardson -Original Message- From: Kern Sibbald [mailto:k...@sibbald.com] Sent: Saturday, April 1, 2017 10:28 AM To: Jim Richardson <j...@securit360.com>; Alan Brown <a...@mssl.ucl.ac.uk>; bacula-users@lists.sourceforge.net Subject: Re: [Bacula-users] Dell TL1000 IBM3850-HH7 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:a...@mssl.ucl.ac.uk] > Sent: Friday, March 31, 2017 3:08 PM > To: bacula-users@lists.sourceforge.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=ibm/Storage_Tape/Tape+device+drivers > ease=1.0=Linux=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
Re: [Bacula-users] Dell TL1000 IBM3850-HH7
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:a...@mssl.ucl.ac.uk] > Sent: Friday, March 31, 2017 3:08 PM > To: bacula-users@lists.sourceforge.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=ibm/Storage_Tape/Tape+device+drivers=1.0=Linux=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
Re: [Bacula-users] Dell TL1000 IBM3850-HH7
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? Jim Richardson -Original Message- From: Alan Brown [mailto:a...@mssl.ucl.ac.uk] Sent: Friday, March 31, 2017 3:08 PM To: bacula-users@lists.sourceforge.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=ibm/Storage_Tape/Tape+device+drivers=1.0=Linux=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: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
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=ibm/Storage_Tape/Tape+device+drivers=1.0=Linux=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: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 installa
Re: [Bacula-users] Dell TL1000 IBM3850-HH7
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
Re: [Bacula-users] Dell TL1000 IBM3850-HH7
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
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.
--
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
Re: [Bacula-users] Dell TL1000 IBM3850-HH7
Kern, Thank you for the additional information. I will look deeper into it throughout the next couple of days. The results of my testing with the code indicate another issue, basically the changes just push the issue further down the process. The first 3 test succeed but the 4th one fails differently. I also concur that replacing EIO with EOF/EOT/EOD is just plan dangerous. EIO is an error for a reason :) Be in touch. Jim Richardson -Original Message- From: Kern Sibbald [mailto:k...@sibbald.com] Sent: Monday, March 20, 2017 8:25 AM To: Jim Richardson <j...@securit360.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 Hello Jim, I just had another thought. Perhaps you have somehow gotten a non-standard ioctl MTSETDRVBUFFER value. This could cause the tape drive to misbehave. There are quite a number of options, and Bacula counts on a certain number of them being correctly set, which is the Linux default. For example, if you have the option MT_ST_SYSV option enabled, Bacula will definitely not work. Also, if the drive has MT_ST_ASYNC_WRITES set, Bacula will also not behave correctly. I know how to set these variables (with an ioctl, documented in "man st"), but I do not know how to find out what they are set to. It is also possible that the tape drive itself, in the firmware has the equivalent to MT_ST_ASYNC_WRITES set. I have seen this for one customer we had, and the only way was for him to modify the firmware setting (I am not sure how he did it). Although it is a good idea for testing, I am not at all comfortable with having an EIO be turned into and EOF or EOT. Best regards, Kern On 03/19/2017 06:02 PM, Jim Richardson wrote: > Team, > > Okay curiosity got the better of me, I did three things. One, built from > latest source on Sourceforge 7.4.7-7 binaries only - tested with same > results. Two, using the Slaanesh repository (thank you Ben) was able to > install version 7.4.7-1 - tested with the same results. Three, I used the > configuration from Alan (thank you) - test with same results. > > At this point I am leaning towards the post from Mariusz Mazur (link below) > from 2013. He is asserting that he is able to use the IBM lin_tape driver > with Bacula by building in support for EOD operations using FSF which end up > with an EIO instead of an EOF. He offers two patches. I am not interested > in the IBM driver if I can get the ST to work. Bacula's code changed > significantly since his patches and my initial debug, notably the calls in > dev.c seem to have moved to tape_dev.c. I may attempt to add a few more Dmsg > at a higher debug to the code reporting on any sense data from the tape > itself to dig into the issue. I am fairly sure from my initial debug of > btape that the EIO instead of an EOF / ENOSPC is the root of the issue. > > Is there anything already in the code that can give insight into the sense > data from the drive without the need for extra code? Or a non-coding option > to get btape to ignore these errors and just complete its job. Then we can > look at the actual tape results to see if, while in error, desired > functionality is obtained? My use case will be one job/tape a day anyway. > The append functionality will only come into play for one offs - which I can > do with mt/tar/etc. > > I am compiling a build that blanketly accepts EIO as EOF to see if that fixes > the issue, if that works then a portion Mariusz's code may be the fix, allow > for an option of EIO at EOF = yes, default of no as it applies this to the > FSF function. > > Be in touch. > > Referenced Link: > http://bacula.10910.n7.nabble.com/No-EIO-support-on-EOD-read-td75874.h > tml > > Jim Richardson > > -Original Message- > From: Kern Sibbald [mailto:k...@sibbald.com] > Sent: Sunday, March 19, 2017 5:13 AM > To: Jim Richardson <j...@securit360.com>; > bacula-users@lists.sourceforge.net > Cc: Simone Caronni <negativ...@gmail.com> > Subject: Re: [Bacula-users] Dell TL1000 IBM3850-HH7 > > Hello Jim, > > What Alan says is interesting. I was aware that there was a recent bug with > btape "fill", but I have been unaware of the kinds of problems you are > seeing. Anyway, your problem worries me as it is possible, though unlikely, > there is some issue with LTO-7 drives. > > Yesterday, I just upgraded from LTO-4 to LTO-5, and btape worked perfectly > for me. > > If I were in your shoes, I would do it just as you say, but if you prefer not > to build the binaries yourself, there are two alternatives: > > 1. Wait a week or two an
Re: [Bacula-users] Dell TL1000 IBM3850-HH7
Hello Jim, I just had another thought. Perhaps you have somehow gotten a non-standard ioctl MTSETDRVBUFFER value. This could cause the tape drive to misbehave. There are quite a number of options, and Bacula counts on a certain number of them being correctly set, which is the Linux default. For example, if you have the option MT_ST_SYSV option enabled, Bacula will definitely not work. Also, if the drive has MT_ST_ASYNC_WRITES set, Bacula will also not behave correctly. I know how to set these variables (with an ioctl, documented in "man st"), but I do not know how to find out what they are set to. It is also possible that the tape drive itself, in the firmware has the equivalent to MT_ST_ASYNC_WRITES set. I have seen this for one customer we had, and the only way was for him to modify the firmware setting (I am not sure how he did it). Although it is a good idea for testing, I am not at all comfortable with having an EIO be turned into and EOF or EOT. Best regards, Kern On 03/19/2017 06:02 PM, Jim Richardson wrote: > Team, > > Okay curiosity got the better of me, I did three things. One, built from > latest source on Sourceforge 7.4.7-7 binaries only - tested with same > results. Two, using the Slaanesh repository (thank you Ben) was able to > install version 7.4.7-1 - tested with the same results. Three, I used the > configuration from Alan (thank you) - test with same results. > > At this point I am leaning towards the post from Mariusz Mazur (link below) > from 2013. He is asserting that he is able to use the IBM lin_tape driver > with Bacula by building in support for EOD operations using FSF which end up > with an EIO instead of an EOF. He offers two patches. I am not interested > in the IBM driver if I can get the ST to work. Bacula's code changed > significantly since his patches and my initial debug, notably the calls in > dev.c seem to have moved to tape_dev.c. I may attempt to add a few more Dmsg > at a higher debug to the code reporting on any sense data from the tape > itself to dig into the issue. I am fairly sure from my initial debug of > btape that the EIO instead of an EOF / ENOSPC is the root of the issue. > > Is there anything already in the code that can give insight into the sense > data from the drive without the need for extra code? Or a non-coding option > to get btape to ignore these errors and just complete its job. Then we can > look at the actual tape results to see if, while in error, desired > functionality is obtained? My use case will be one job/tape a day anyway. > The append functionality will only come into play for one offs - which I can > do with mt/tar/etc. > > I am compiling a build that blanketly accepts EIO as EOF to see if that fixes > the issue, if that works then a portion Mariusz's code may be the fix, allow > for an option of EIO at EOF = yes, default of no as it applies this to the > FSF function. > > Be in touch. > > Referenced Link: > http://bacula.10910.n7.nabble.com/No-EIO-support-on-EOD-read-td75874.html > > Jim Richardson > > -Original Message- > From: Kern Sibbald [mailto:k...@sibbald.com] > Sent: Sunday, March 19, 2017 5:13 AM > To: Jim Richardson <j...@securit360.com>; bacula-users@lists.sourceforge.net > Cc: Simone Caronni <negativ...@gmail.com> > Subject: Re: [Bacula-users] Dell TL1000 IBM3850-HH7 > > Hello Jim, > > What Alan says is interesting. I was aware that there was a recent bug with > btape "fill", but I have been unaware of the kinds of problems you are > seeing. Anyway, your problem worries me as it is possible, though unlikely, > there is some issue with LTO-7 drives. > > Yesterday, I just upgraded from LTO-4 to LTO-5, and btape worked perfectly > for me. > > If I were in your shoes, I would do it just as you say, but if you prefer not > to build the binaries yourself, there are two alternatives: > > 1. Wait a week or two and the community will certainly have RedHat or CentOS > 7.x binaries available. We are just putting the finishing touches on the > download page. > > 2. Ask Simone Caronni, copied on this email, as he is the RedHat/Fedora > packager and he probably already has a recent RedHat 7.4 packaged. The > current Bacula release is 7.4.7. > > Best regards, > > Kern > > > On 03/19/2017 12:42 AM, Jim Richardson wrote: >> Alan, >> >> Thank you for joining my inquiry. I will try this config on Monday. As for >> the bug, no and kind of, I read a thread from 2013 that pointed to a fix for >> the FSF calls for EOF/EOT with LTO drives. It includes a few patches and >> questioned their plausibility for inclusion into Bacula stating that it >> would make Bacula co
Re: [Bacula-users] Dell TL1000 IBM3850-HH7
Team, Okay curiosity got the better of me, I did three things. One, built from latest source on Sourceforge 7.4.7-7 binaries only - tested with same results. Two, using the Slaanesh repository (thank you Ben) was able to install version 7.4.7-1 - tested with the same results. Three, I used the configuration from Alan (thank you) - test with same results. At this point I am leaning towards the post from Mariusz Mazur (link below) from 2013. He is asserting that he is able to use the IBM lin_tape driver with Bacula by building in support for EOD operations using FSF which end up with an EIO instead of an EOF. He offers two patches. I am not interested in the IBM driver if I can get the ST to work. Bacula's code changed significantly since his patches and my initial debug, notably the calls in dev.c seem to have moved to tape_dev.c. I may attempt to add a few more Dmsg at a higher debug to the code reporting on any sense data from the tape itself to dig into the issue. I am fairly sure from my initial debug of btape that the EIO instead of an EOF / ENOSPC is the root of the issue. Is there anything already in the code that can give insight into the sense data from the drive without the need for extra code? Or a non-coding option to get btape to ignore these errors and just complete its job. Then we can look at the actual tape results to see if, while in error, desired functionality is obtained? My use case will be one job/tape a day anyway. The append functionality will only come into play for one offs - which I can do with mt/tar/etc. I am compiling a build that blanketly accepts EIO as EOF to see if that fixes the issue, if that works then a portion Mariusz's code may be the fix, allow for an option of EIO at EOF = yes, default of no as it applies this to the FSF function. Be in touch. Referenced Link: http://bacula.10910.n7.nabble.com/No-EIO-support-on-EOD-read-td75874.html Jim Richardson -Original Message- From: Kern Sibbald [mailto:k...@sibbald.com] Sent: Sunday, March 19, 2017 5:13 AM To: Jim Richardson <j...@securit360.com>; bacula-users@lists.sourceforge.net Cc: Simone Caronni <negativ...@gmail.com> Subject: Re: [Bacula-users] Dell TL1000 IBM3850-HH7 Hello Jim, What Alan says is interesting. I was aware that there was a recent bug with btape "fill", but I have been unaware of the kinds of problems you are seeing. Anyway, your problem worries me as it is possible, though unlikely, there is some issue with LTO-7 drives. Yesterday, I just upgraded from LTO-4 to LTO-5, and btape worked perfectly for me. If I were in your shoes, I would do it just as you say, but if you prefer not to build the binaries yourself, there are two alternatives: 1. Wait a week or two and the community will certainly have RedHat or CentOS 7.x binaries available. We are just putting the finishing touches on the download page. 2. Ask Simone Caronni, copied on this email, as he is the RedHat/Fedora packager and he probably already has a recent RedHat 7.4 packaged. The current Bacula release is 7.4.7. Best regards, Kern On 03/19/2017 12:42 AM, Jim Richardson wrote: > Alan, > > Thank you for joining my inquiry. I will try this config on Monday. As for > the bug, no and kind of, I read a thread from 2013 that pointed to a fix for > the FSF calls for EOF/EOT with LTO drives. It includes a few patches and > questioned their plausibility for inclusion into Bacula stating that it would > make Bacula compatible with the IBM lin_tape driver. The thread died with > what seemed like internet trollism. I wanted to avoid building from source > due to the fact that I know it will tie me to the install forever. Never the > less, if that is the only way to get this moving forward I will do so Monday > and will report back with results. I am using bacula-7.0.5-7 which looks > like it was packaged for el7 in May of 2015. I will use the SPEC and related > files from it with the latest source and see where things go. > > Thank you again > > Jim Richardson > > -Original Message- > From: Alan Brown [mailto:a.br...@ucl.ac.uk] > Sent: Saturday, March 18, 2017 1:01 PM > To: Kern Sibbald <k...@sibbald.com>; Jim Richardson > <j...@securit360.com>; bacula-users@lists.sourceforge.net > Subject: Re: [Bacula-users] Dell TL1000 IBM3850-HH7 > > On 18/03/17 07:41, Kern Sibbald wrote: >> Hello Jim, >> >> I am checking with a tape drive "expert" perhaps he has some ideas. >> My problem is time, not money. > I'm no expert, just someone who's had to debug things :) > > Thankfully all ultrium(LTO) drives behave the same no matter who > they're made by and I see you're using the generic st driver > > > > > I take it you're aware there was a bug introduced into older versions of > btape w
Re: [Bacula-users] Dell TL1000 IBM3850-HH7
Hi Jim, > I am using bacula-7.0.5-7 which looks like it was packaged for el7 in May of > 2015. I will use the SPEC and related files from it with the latest source > and see where things go. If you're looking for newer el6/7 releases to avoid building from source, take a look at Slaanesh's COPR repository: https://copr.fedorainfracloud.org/coprs/slaanesh/Bacula/. These include the latest releases since Jan 2017 and so will contain the btape fixes mentioned earlier in this thread. Regards, Ben Roberts This email and any files transmitted with it contain confidential and proprietary information and is solely for the use of the intended recipient. If you are not the intended recipient please return the email to the sender and delete it from your computer and you must not use, disclose, distribute, copy, print or rely on this email or its contents. This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. Any comments or statements made herein do not necessarily reflect those of GSA Capital. GSA Capital Partners LLP is authorised and regulated by the Financial Conduct Authority and is registered in England and Wales at Stratton House, 5 Stratton Street, London W1J 8LA, number OC309261. GSA Capital Services Limited is registered in England and Wales at the same address, number 5320529. -- 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
Re: [Bacula-users] Dell TL1000 IBM3850-HH7
Hello Jim,
What Alan says is interesting. I was aware that there was a recent bug
with btape "fill", but I have been unaware of the kinds of problems you
are seeing. Anyway, your problem worries me as it is possible, though
unlikely, there is some issue with LTO-7 drives.
Yesterday, I just upgraded from LTO-4 to LTO-5, and btape worked
perfectly for me.
If I were in your shoes, I would do it just as you say, but if you
prefer not to build the binaries yourself, there are two alternatives:
1. Wait a week or two and the community will certainly have RedHat or
CentOS 7.x binaries available. We are just putting the finishing
touches on the download page.
2. Ask Simone Caronni, copied on this email, as he is the RedHat/Fedora
packager and he probably already has a recent RedHat 7.4 packaged. The
current Bacula release is 7.4.7.
Best regards,
Kern
On 03/19/2017 12:42 AM, Jim Richardson wrote:
> Alan,
>
> Thank you for joining my inquiry. I will try this config on Monday. As for
> the bug, no and kind of, I read a thread from 2013 that pointed to a fix for
> the FSF calls for EOF/EOT with LTO drives. It includes a few patches and
> questioned their plausibility for inclusion into Bacula stating that it would
> make Bacula compatible with the IBM lin_tape driver. The thread died with
> what seemed like internet trollism. I wanted to avoid building from source
> due to the fact that I know it will tie me to the install forever. Never the
> less, if that is the only way to get this moving forward I will do so Monday
> and will report back with results. I am using bacula-7.0.5-7 which looks
> like it was packaged for el7 in May of 2015. I will use the SPEC and related
> files from it with the latest source and see where things go.
>
> Thank you again
>
> Jim Richardson
>
> -Original Message-
> From: Alan Brown [mailto:a.br...@ucl.ac.uk]
> Sent: Saturday, March 18, 2017 1:01 PM
> To: Kern Sibbald <k...@sibbald.com>; Jim Richardson <j...@securit360.com>;
> bacula-users@lists.sourceforge.net
> Subject: Re: [Bacula-users] Dell TL1000 IBM3850-HH7
>
> On 18/03/17 07:41, Kern Sibbald wrote:
>> Hello Jim,
>>
>> I am checking with a tape drive "expert" perhaps he has some ideas.
>> My problem is time, not money.
> I'm no expert, just someone who's had to debug things :)
>
> Thankfully all ultrium(LTO) drives behave the same no matter who they're made
> by and I see you're using the generic st driver
>
>
>
>
> I take it you're aware there was a bug introduced into older versions of
> btape which will result in tests failing?
> It's important to be running a bacula version from after January 2017 to
> avoid this.
>
>
>
>
>
> This is my current config (IBM SAS LTO6 drive in a Quantum i500 robot) - as
> you can see I just run them in as vanilla a state as possible.
>
> The configuration for the previous setup (HP FC LTO5 drives in a Neo8000
> robot) was almost identical.
>
> The /etc/bacula/DEVICE/* items are symlinks to /dev/tape/by-id/ in order to
> make identification of the drives easier for operators.
> In a single drive setup there's no advantage to this over using /dev/nst0
>
> Device {
> ## NB: THIS IS THE PATH TO THE CHANGER. IF YOU LOSE THIS DRIVE, YOU LOSE
> CONTROL.
> ### library physical position 0,2
>Name = MSSLYF-5
>Drive Index = 5
>Device Type = Tape
>Media Type = LTO5
>AutoChanger = yes ;
>Autoselect = yes ## change to no to prevent bacula using the drive
>Archive Device = /etc/bacula/DEVICES/MSSLYF-5
>Control Device = /etc/bacula/DEVICES/MSSLYF-5-sg # beyond this number of
> jobs for a drive, bacula will attempt # to load another tape in the same pool
> in another drive
>Maximum Concurrent Jobs = 40
> # allow for cleaning cycles
>Maximum Changer Wait = 20 minutes
>AutomaticMount = yes; # when device opened, read it
>AlwaysOpen = yes;
>LabelMedia = yes; # lets Bacula label unlabeled media
>RemovableMedia = yes;
>RandomAccess = no;
>Volume Poll Interval = 600
>#Alert Command = "sh -c '/usr/local/bin/gettapeinfo.sh
> /etc/bacula/DEVICES/MSSLYF-5'"
>Alert Command = /opt/bacula/scripts/tapealert %l
>Spool Directory = /var/bacula/spool/TAPE
>Maximum File Size = 16G
>Maximum Network Buffer Size = 262144
>Maximum block size = 2M
>Maximum Spool Size = 220G
>Maximum Job Spool Size = 50G
> }
>
>> What OS and version are you using, and what version of Bacula are you
>> using (sorry if you already answered these questions).
>>
>> Best regards,
>>
>> Kern
>>
>
Re: [Bacula-users] Dell TL1000 IBM3850-HH7
Kern,
I do appreciate you looking into this.
# lsb_release -a
LSB Version::core-4.1-amd64:core-4.1-noarch
Distributor ID: CentOS
Description:CentOS Linux release 7.3.1611 (Core)
Release:7.3.1611
Codename: Core
# uname -r
3.10.0-514.10.2.el7.x86_64
# rpm -qa | grep bacula
bacula-libs-sql-7.0.5-7.el7.x86_64
bacula-console-7.0.5-7.el7.x86_64
bacula-director-7.0.5-7.el7.x86_64
bacula-libs-7.0.5-7.el7.x86_64
bacula-storage-7.0.5-7.el7.x86_64
bacula-common-7.0.5-7.el7.x86_64
bacula-client-7.0.5-7.el7.x86_64
Jim Richardson
CISSP CISA
SecurIT360
-Original Message-
From: Kern Sibbald [mailto:k...@sibbald.com]
Sent: Saturday, March 18, 2017 2:41 AM
To: Jim Richardson <j...@securit360.com>; bacula-users@lists.sourceforge.net
Subject: Re: [Bacula-users] Dell TL1000 IBM3850-HH7
Hello Jim,
I am checking with a tape drive "expert" perhaps he has some ideas. My problem
is time, not money.
What OS and version are you using, and what version of Bacula are you using
(sorry if you already answered these questions).
Best regards,
Kern
On 03/17/2017 08:02 PM, Jim Richardson wrote:
> Kern,
>
> Unfortunately both of your options did not work. Both failed with the exact
> same results. I would really like to get this solution running even if it
> means I have to put some dollars into it. The drive I have is new
> manufactured in 12/2015 with the latest firmware from 1/2016. I took the
> cover off the library and the drive itself is labeled as a LTO Ultrium 7-H
> SAS with the same markings as an IBM TS2270. When I look up the TS2270 is
> spot on. It's designation is Model 3580 H7(S) - (S) for SAS as in my case
> or (F) for fiber channel.
>
> http://www-03.ibm.com/systems/storage/tape/ts2270/specifications.html
>
> Crazy how incestuous our technology manufacturers are.
>
> Jim Richardson
>
> -Original Message-
> From: Kern Sibbald [mailto:k...@sibbald.com]
> Sent: Friday, March 17, 2017 11:53 AM
> To: Jim Richardson <j...@securit360.com>;
> bacula-users@lists.sourceforge.net
> Subject: Re: [Bacula-users] Dell TL1000 IBM3850-HH7
>
> Hello Jim,
>
> mt does not generally do the same operations as Bacula. Bacula uses many
> more ioctl calls.
>
> I recommend to first try using the HP-UX tape drive configuration in
> bacula-sd.conf. This reduces the use of more modern features such as
> hardware EOM where the drive knows where the end of data is and how to seek
> to it.
>
> Then try using the FreeBSD configuration. This reduces even more the use of
> more modern features and accomplishes many functions using the very simple
> tape ioctl calls.
>
> One or the other will probably work for you. If not, you have a rather
> strange drive, and Bacula can probably adapt to it, but it takes a good
> knowledge of tape drives and the ioctl calls and quite a lot of time.
>
> Is this one of those new LTO-7 drives or is it an old drive. In searching
> Internet, I don't find any specifications for it.
>
> Best regards,
>
> Kern
>
>
>
>
> On 03/17/2017 05:16 PM, Jim Richardson wrote:
>> Good Morning,
>>
>> Thank you for your response. I have done as instructed, basically where I
>> started off with the exact results. I am not using the IBM driver as shown
>> below with my lsmod results. The errors seems to be around the responses to
>> the FSF when Bacula is trying to reach EOF/EOT. First attempt is obviously
>> EOT of the medium limit shown by tapeinfo. The second is correct and
>> attempts to write a fourth file. After the file is written the tape is
>> rewound, then each file is read again, when Bacula reaches EOF of the fourth
>> file it errors out.
>>
>> What are the configuration options that control how Bacula accepts EOF/EOT?
>> Mt has two-fms for EOF, Bacula has several all of which I have tried.
>> Hardware End of Medium, Fast Forward Space File, Use MTIOCGET, BSF at EOM,
>> Two EOM all of which either return the same result or kick out a different
>> error like "reposition error". The worst part of this is that I can
>> control the tape drive with mt all day long with no issues. I can replicate
>> the append procedure using mt commands.
>>
>>
>>
>> ## bacula-sd.conf
>> #
>> # A Linux or Solaris LTO-7 tape drive # Device {
>> Name = ULT3580-HH7
>> Media Type = LTO-7
>> Archive Device = /dev/nst0
>> AutomaticMount = yes; # when device opened, read it
>> AlwaysOpen = yes;
>> RemovableMedia = yes;
>> RandomAccess = no;
>> # Maximum File Size = 5GB
>> Cha
Re: [Bacula-users] Dell TL1000 IBM3850-HH7
Alan,
Thank you for joining my inquiry. I will try this config on Monday. As for
the bug, no and kind of, I read a thread from 2013 that pointed to a fix for
the FSF calls for EOF/EOT with LTO drives. It includes a few patches and
questioned their plausibility for inclusion into Bacula stating that it would
make Bacula compatible with the IBM lin_tape driver. The thread died with what
seemed like internet trollism. I wanted to avoid building from source due to
the fact that I know it will tie me to the install forever. Never the less, if
that is the only way to get this moving forward I will do so Monday and will
report back with results. I am using bacula-7.0.5-7 which looks like it was
packaged for el7 in May of 2015. I will use the SPEC and related files from it
with the latest source and see where things go.
Thank you again
Jim Richardson
-Original Message-
From: Alan Brown [mailto:a.br...@ucl.ac.uk]
Sent: Saturday, March 18, 2017 1:01 PM
To: Kern Sibbald <k...@sibbald.com>; Jim Richardson <j...@securit360.com>;
bacula-users@lists.sourceforge.net
Subject: Re: [Bacula-users] Dell TL1000 IBM3850-HH7
On 18/03/17 07:41, Kern Sibbald wrote:
> Hello Jim,
>
> I am checking with a tape drive "expert" perhaps he has some ideas.
> My problem is time, not money.
I'm no expert, just someone who's had to debug things :)
Thankfully all ultrium(LTO) drives behave the same no matter who they're made
by and I see you're using the generic st driver
I take it you're aware there was a bug introduced into older versions of btape
which will result in tests failing?
It's important to be running a bacula version from after January 2017 to avoid
this.
This is my current config (IBM SAS LTO6 drive in a Quantum i500 robot) - as you
can see I just run them in as vanilla a state as possible.
The configuration for the previous setup (HP FC LTO5 drives in a Neo8000
robot) was almost identical.
The /etc/bacula/DEVICE/* items are symlinks to /dev/tape/by-id/ in order to
make identification of the drives easier for operators.
In a single drive setup there's no advantage to this over using /dev/nst0
Device {
## NB: THIS IS THE PATH TO THE CHANGER. IF YOU LOSE THIS DRIVE, YOU LOSE
CONTROL.
### library physical position 0,2
Name = MSSLYF-5
Drive Index = 5
Device Type = Tape
Media Type = LTO5
AutoChanger = yes ;
Autoselect = yes ## change to no to prevent bacula using the drive
Archive Device = /etc/bacula/DEVICES/MSSLYF-5
Control Device = /etc/bacula/DEVICES/MSSLYF-5-sg # beyond this number of jobs
for a drive, bacula will attempt # to load another tape in the same pool in
another drive
Maximum Concurrent Jobs = 40
# allow for cleaning cycles
Maximum Changer Wait = 20 minutes
AutomaticMount = yes; # when device opened, read it
AlwaysOpen = yes;
LabelMedia = yes; # lets Bacula label unlabeled media
RemovableMedia = yes;
RandomAccess = no;
Volume Poll Interval = 600
#Alert Command = "sh -c '/usr/local/bin/gettapeinfo.sh
/etc/bacula/DEVICES/MSSLYF-5'"
Alert Command = /opt/bacula/scripts/tapealert %l
Spool Directory = /var/bacula/spool/TAPE
Maximum File Size = 16G
Maximum Network Buffer Size = 262144
Maximum block size = 2M
Maximum Spool Size = 220G
Maximum Job Spool Size = 50G
}
>
> What OS and version are you using, and what version of Bacula are you
> using (sorry if you already answered these questions).
>
> Best regards,
>
> Kern
>
>
> On 03/17/2017 08:02 PM, Jim Richardson wrote:
>> Kern,
>>
>> Unfortunately both of your options did not work. Both failed with the exact
>> same results. I would really like to get this solution running even if it
>> means I have to put some dollars into it. The drive I have is new
>> manufactured in 12/2015 with the latest firmware from 1/2016. I took the
>> cover off the library and the drive itself is labeled as a LTO Ultrium 7-H
>> SAS with the same markings as an IBM TS2270. When I look up the TS2270 is
>> spot on. It's designation is Model 3580 H7(S) - (S) for SAS as in my case
>> or (F) for fiber channel.
>>
>> http://www-03.ibm.com/systems/storage/tape/ts2270/specifications.html
>>
>> Crazy how incestuous our technology manufacturers are.
>>
>> Jim Richardson
>>
>> -Original Message-
>> From: Kern Sibbald [mailto:k...@sibbald.com]
>> Sent: Friday, March 17, 2017 11:53 AM
>> To: Jim Richardson <j...@securit360.com>;
>> bacula-users@lists.sourceforge.net
>> Subject: Re: [Bacula-users] Dell TL1000 IBM3850-HH7
>>
>> Hello Jim,
>>
>> mt does not generally do the same operations as Bacula. Bacula uses many
>> more ioctl calls.
>>
>> I recommend to first try using the HP-UX tape
Re: [Bacula-users] Dell TL1000 IBM3850-HH7
On 18/03/17 07:41, Kern Sibbald wrote:
> Hello Jim,
>
> I am checking with a tape drive "expert" perhaps he has some ideas. My
> problem is time, not money.
I'm no expert, just someone who's had to debug things :)
Thankfully all ultrium(LTO) drives behave the same no matter who they're
made by and I see you're using the generic st driver
I take it you're aware there was a bug introduced into older versions of
btape which will result in tests failing?
It's important to be running a bacula version from after January 2017 to
avoid this.
This is my current config (IBM SAS LTO6 drive in a Quantum i500 robot) -
as you can see I just run them in as vanilla a state as possible.
The configuration for the previous setup (HP FC LTO5 drives in a Neo8000
robot) was almost identical.
The /etc/bacula/DEVICE/* items are symlinks to /dev/tape/by-id/ in order
to make identification of the drives easier for operators.
In a single drive setup there's no advantage to this over using /dev/nst0
Device {
## NB: THIS IS THE PATH TO THE CHANGER. IF YOU LOSE THIS DRIVE, YOU LOSE
CONTROL.
### library physical position 0,2
Name = MSSLYF-5
Drive Index = 5
Device Type = Tape
Media Type = LTO5
AutoChanger = yes ;
Autoselect = yes ## change to no to prevent bacula using the drive
Archive Device = /etc/bacula/DEVICES/MSSLYF-5
Control Device = /etc/bacula/DEVICES/MSSLYF-5-sg
# beyond this number of jobs for a drive, bacula will attempt
# to load another tape in the same pool in another drive
Maximum Concurrent Jobs = 40
# allow for cleaning cycles
Maximum Changer Wait = 20 minutes
AutomaticMount = yes; # when device opened, read it
AlwaysOpen = yes;
LabelMedia = yes; # lets Bacula label unlabeled media
RemovableMedia = yes;
RandomAccess = no;
Volume Poll Interval = 600
#Alert Command = "sh -c '/usr/local/bin/gettapeinfo.sh
/etc/bacula/DEVICES/MSSLYF-5'"
Alert Command = /opt/bacula/scripts/tapealert %l
Spool Directory = /var/bacula/spool/TAPE
Maximum File Size = 16G
Maximum Network Buffer Size = 262144
Maximum block size = 2M
Maximum Spool Size = 220G
Maximum Job Spool Size = 50G
}
>
> What OS and version are you using, and what version of Bacula are you
> using (sorry if you already answered these questions).
>
> Best regards,
>
> Kern
>
>
> On 03/17/2017 08:02 PM, Jim Richardson wrote:
>> Kern,
>>
>> Unfortunately both of your options did not work. Both failed with the exact
>> same results. I would really like to get this solution running even if it
>> means I have to put some dollars into it. The drive I have is new
>> manufactured in 12/2015 with the latest firmware from 1/2016. I took the
>> cover off the library and the drive itself is labeled as a LTO Ultrium 7-H
>> SAS with the same markings as an IBM TS2270. When I look up the TS2270 is
>> spot on. It's designation is Model 3580 H7(S) - (S) for SAS as in my case
>> or (F) for fiber channel.
>>
>> http://www-03.ibm.com/systems/storage/tape/ts2270/specifications.html
>>
>> Crazy how incestuous our technology manufacturers are.
>>
>> Jim Richardson
>>
>> -Original Message-
>> From: Kern Sibbald [mailto:k...@sibbald.com]
>> Sent: Friday, March 17, 2017 11:53 AM
>> To: Jim Richardson <j...@securit360.com>; bacula-users@lists.sourceforge.net
>> Subject: Re: [Bacula-users] Dell TL1000 IBM3850-HH7
>>
>> Hello Jim,
>>
>> mt does not generally do the same operations as Bacula. Bacula uses many
>> more ioctl calls.
>>
>> I recommend to first try using the HP-UX tape drive configuration in
>> bacula-sd.conf. This reduces the use of more modern features such as
>> hardware EOM where the drive knows where the end of data is and how to seek
>> to it.
>>
>> Then try using the FreeBSD configuration. This reduces even more the use of
>> more modern features and accomplishes many functions using the very simple
>> tape ioctl calls.
>>
>> One or the other will probably work for you. If not, you have a rather
>> strange drive, and Bacula can probably adapt to it, but it takes a good
>> knowledge of tape drives and the ioctl calls and quite a lot of time.
>>
>> Is this one of those new LTO-7 drives or is it an old drive. In searching
>> Internet, I don't find any specifications for it.
>>
>> Best regards,
>>
>> Kern
>>
>>
>>
>>
>> On 03/17/2017 05:16 PM, Jim Richardson wrote:
>>> Good Morning,
>>>
>>> Thank you for your response. I have done as instructed, basically where I
>>> started off with the exact results. I am not using the IBM driver as shown
>
Re: [Bacula-users] Dell TL1000 IBM3850-HH7
Hello Jim,
I am checking with a tape drive "expert" perhaps he has some ideas. My
problem is time, not money.
What OS and version are you using, and what version of Bacula are you
using (sorry if you already answered these questions).
Best regards,
Kern
On 03/17/2017 08:02 PM, Jim Richardson wrote:
> Kern,
>
> Unfortunately both of your options did not work. Both failed with the exact
> same results. I would really like to get this solution running even if it
> means I have to put some dollars into it. The drive I have is new
> manufactured in 12/2015 with the latest firmware from 1/2016. I took the
> cover off the library and the drive itself is labeled as a LTO Ultrium 7-H
> SAS with the same markings as an IBM TS2270. When I look up the TS2270 is
> spot on. It's designation is Model 3580 H7(S) - (S) for SAS as in my case
> or (F) for fiber channel.
>
> http://www-03.ibm.com/systems/storage/tape/ts2270/specifications.html
>
> Crazy how incestuous our technology manufacturers are.
>
> Jim Richardson
>
> -Original Message-
> From: Kern Sibbald [mailto:k...@sibbald.com]
> Sent: Friday, March 17, 2017 11:53 AM
> To: Jim Richardson <j...@securit360.com>; bacula-users@lists.sourceforge.net
> Subject: Re: [Bacula-users] Dell TL1000 IBM3850-HH7
>
> Hello Jim,
>
> mt does not generally do the same operations as Bacula. Bacula uses many
> more ioctl calls.
>
> I recommend to first try using the HP-UX tape drive configuration in
> bacula-sd.conf. This reduces the use of more modern features such as
> hardware EOM where the drive knows where the end of data is and how to seek
> to it.
>
> Then try using the FreeBSD configuration. This reduces even more the use of
> more modern features and accomplishes many functions using the very simple
> tape ioctl calls.
>
> One or the other will probably work for you. If not, you have a rather
> strange drive, and Bacula can probably adapt to it, but it takes a good
> knowledge of tape drives and the ioctl calls and quite a lot of time.
>
> Is this one of those new LTO-7 drives or is it an old drive. In searching
> Internet, I don't find any specifications for it.
>
> Best regards,
>
> Kern
>
>
>
>
> On 03/17/2017 05:16 PM, Jim Richardson wrote:
>> Good Morning,
>>
>> Thank you for your response. I have done as instructed, basically where I
>> started off with the exact results. I am not using the IBM driver as shown
>> below with my lsmod results. The errors seems to be around the responses to
>> the FSF when Bacula is trying to reach EOF/EOT. First attempt is obviously
>> EOT of the medium limit shown by tapeinfo. The second is correct and
>> attempts to write a fourth file. After the file is written the tape is
>> rewound, then each file is read again, when Bacula reaches EOF of the fourth
>> file it errors out.
>>
>> What are the configuration options that control how Bacula accepts EOF/EOT?
>> Mt has two-fms for EOF, Bacula has several all of which I have tried.
>> Hardware End of Medium, Fast Forward Space File, Use MTIOCGET, BSF at EOM,
>> Two EOM all of which either return the same result or kick out a different
>> error like "reposition error". The worst part of this is that I can
>> control the tape drive with mt all day long with no issues. I can replicate
>> the append procedure using mt commands.
>>
>>
>>
>> ## bacula-sd.conf
>> #
>> # A Linux or Solaris LTO-7 tape drive
>> #
>> Device {
>> Name = ULT3580-HH7
>> Media Type = LTO-7
>> Archive Device = /dev/nst0
>> AutomaticMount = yes; # when device opened, read it
>> AlwaysOpen = yes;
>> RemovableMedia = yes;
>> RandomAccess = no;
>> # Maximum File Size = 5GB
>> Changer Command = "/usr/libexec/bacula/mtx-changer %c %o %S %a %d"
>> Changer Device = /dev/sg3
>> AutoChanger = yes
>> # # Enable the Alert command only if you have the mtx package loaded
>> Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'"
>> ## If you have smartctl, enable this, it has more info than tapeinfo
>> ## Alert Command = "sh -c 'smartctl -H -l error %c'"
>> }
>>
>>
>> ## lsmod | grep 'st\|ibm'
>> dm_persistent_data 67216 1 dm_thin_pool
>> dm_bufio 27972 1 dm_persistent_data
>> dm_mod 114430 68 dm_persistent_data,dm_bufio,dm_thin_pool
>> osst 57198 0
>> st 54238 2
>> libcrc32c 1
Re: [Bacula-users] Dell TL1000 IBM3850-HH7
Kern,
Unfortunately both of your options did not work. Both failed with the exact
same results. I would really like to get this solution running even if it
means I have to put some dollars into it. The drive I have is new manufactured
in 12/2015 with the latest firmware from 1/2016. I took the cover off the
library and the drive itself is labeled as a LTO Ultrium 7-H SAS with the same
markings as an IBM TS2270. When I look up the TS2270 is spot on. It's
designation is Model 3580 H7(S) - (S) for SAS as in my case or (F) for fiber
channel.
http://www-03.ibm.com/systems/storage/tape/ts2270/specifications.html
Crazy how incestuous our technology manufacturers are.
Jim Richardson
-Original Message-
From: Kern Sibbald [mailto:k...@sibbald.com]
Sent: Friday, March 17, 2017 11:53 AM
To: Jim Richardson <j...@securit360.com>; bacula-users@lists.sourceforge.net
Subject: Re: [Bacula-users] Dell TL1000 IBM3850-HH7
Hello Jim,
mt does not generally do the same operations as Bacula. Bacula uses many more
ioctl calls.
I recommend to first try using the HP-UX tape drive configuration in
bacula-sd.conf. This reduces the use of more modern features such as hardware
EOM where the drive knows where the end of data is and how to seek to it.
Then try using the FreeBSD configuration. This reduces even more the use of
more modern features and accomplishes many functions using the very simple tape
ioctl calls.
One or the other will probably work for you. If not, you have a rather strange
drive, and Bacula can probably adapt to it, but it takes a good knowledge of
tape drives and the ioctl calls and quite a lot of time.
Is this one of those new LTO-7 drives or is it an old drive. In searching
Internet, I don't find any specifications for it.
Best regards,
Kern
On 03/17/2017 05:16 PM, Jim Richardson wrote:
> Good Morning,
>
> Thank you for your response. I have done as instructed, basically where I
> started off with the exact results. I am not using the IBM driver as shown
> below with my lsmod results. The errors seems to be around the responses to
> the FSF when Bacula is trying to reach EOF/EOT. First attempt is obviously
> EOT of the medium limit shown by tapeinfo. The second is correct and
> attempts to write a fourth file. After the file is written the tape is
> rewound, then each file is read again, when Bacula reaches EOF of the fourth
> file it errors out.
>
> What are the configuration options that control how Bacula accepts EOF/EOT?
> Mt has two-fms for EOF, Bacula has several all of which I have tried.
> Hardware End of Medium, Fast Forward Space File, Use MTIOCGET, BSF at EOM,
> Two EOM all of which either return the same result or kick out a different
> error like "reposition error". The worst part of this is that I can control
> the tape drive with mt all day long with no issues. I can replicate the
> append procedure using mt commands.
>
>
>
> ## bacula-sd.conf
> #
> # A Linux or Solaris LTO-7 tape drive
> #
> Device {
>Name = ULT3580-HH7
>Media Type = LTO-7
>Archive Device = /dev/nst0
>AutomaticMount = yes; # when device opened, read it
>AlwaysOpen = yes;
>RemovableMedia = yes;
>RandomAccess = no;
> # Maximum File Size = 5GB
>Changer Command = "/usr/libexec/bacula/mtx-changer %c %o %S %a %d"
>Changer Device = /dev/sg3
>AutoChanger = yes
> # # Enable the Alert command only if you have the mtx package loaded
>Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'"
> ## If you have smartctl, enable this, it has more info than tapeinfo
> ## Alert Command = "sh -c 'smartctl -H -l error %c'"
> }
>
>
> ## lsmod | grep 'st\|ibm'
> dm_persistent_data 67216 1 dm_thin_pool
> dm_bufio 27972 1 dm_persistent_data
> dm_mod114430 68 dm_persistent_data,dm_bufio,dm_thin_pool
> osst 57198 0
> st 54238 2
> libcrc32c 12644 2 xfs,dm_persistent_data
> usb_storage66762 3 uas
>
>
>
>
> Jim Richardson
>
> -----Original Message-----
> From: Kern Sibbald [mailto:k...@sibbald.com]
> Sent: Friday, March 17, 2017 2:53 AM
> To: Jim Richardson <j...@securit360.com>;
> bacula-users@lists.sourceforge.net
> Subject: Re: [Bacula-users] Dell TL1000 IBM3850-HH7
>
> Hello,
>
> First, remove all the directives you have added to the Device resource in
> your bacula-sd.conf file, and use the standard Device resource for tapes that
> is in the distributed bacula-sd.conf file. Then retry running the test. If
> you need to make changes such as the block size, ..., make the changes and
> rerun the test. If it fa
Re: [Bacula-users] Dell TL1000 IBM3850-HH7
Hello Jim,
mt does not generally do the same operations as Bacula. Bacula uses
many more ioctl calls.
I recommend to first try using the HP-UX tape drive configuration in
bacula-sd.conf. This reduces the use of more modern features such as
hardware EOM where the drive knows where the end of data is and how to
seek to it.
Then try using the FreeBSD configuration. This reduces even more the
use of more modern features and accomplishes many functions using the
very simple tape ioctl calls.
One or the other will probably work for you. If not, you have a rather
strange drive, and Bacula can probably adapt to it, but it takes a good
knowledge of tape drives and the ioctl calls and quite a lot of time.
Is this one of those new LTO-7 drives or is it an old drive. In
searching Internet, I don't find any specifications for it.
Best regards,
Kern
On 03/17/2017 05:16 PM, Jim Richardson wrote:
> Good Morning,
>
> Thank you for your response. I have done as instructed, basically where I
> started off with the exact results. I am not using the IBM driver as shown
> below with my lsmod results. The errors seems to be around the responses to
> the FSF when Bacula is trying to reach EOF/EOT. First attempt is obviously
> EOT of the medium limit shown by tapeinfo. The second is correct and
> attempts to write a fourth file. After the file is written the tape is
> rewound, then each file is read again, when Bacula reaches EOF of the fourth
> file it errors out.
>
> What are the configuration options that control how Bacula accepts EOF/EOT?
> Mt has two-fms for EOF, Bacula has several all of which I have tried.
> Hardware End of Medium, Fast Forward Space File, Use MTIOCGET, BSF at EOM,
> Two EOM all of which either return the same result or kick out a different
> error like "reposition error". The worst part of this is that I can control
> the tape drive with mt all day long with no issues. I can replicate the
> append procedure using mt commands.
>
>
>
> ## bacula-sd.conf
> #
> # A Linux or Solaris LTO-7 tape drive
> #
> Device {
>Name = ULT3580-HH7
>Media Type = LTO-7
>Archive Device = /dev/nst0
>AutomaticMount = yes; # when device opened, read it
>AlwaysOpen = yes;
>RemovableMedia = yes;
>RandomAccess = no;
> # Maximum File Size = 5GB
>Changer Command = "/usr/libexec/bacula/mtx-changer %c %o %S %a %d"
>Changer Device = /dev/sg3
>AutoChanger = yes
> # # Enable the Alert command only if you have the mtx package loaded
>Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'"
> ## If you have smartctl, enable this, it has more info than tapeinfo
> ## Alert Command = "sh -c 'smartctl -H -l error %c'"
> }
>
>
> ## lsmod | grep 'st\|ibm'
> dm_persistent_data 67216 1 dm_thin_pool
> dm_bufio 27972 1 dm_persistent_data
> dm_mod114430 68 dm_persistent_data,dm_bufio,dm_thin_pool
> osst 57198 0
> st 54238 2
> libcrc32c 12644 2 xfs,dm_persistent_data
> usb_storage66762 3 uas
>
>
>
>
> Jim Richardson
>
> -----Original Message-----
> From: Kern Sibbald [mailto:k...@sibbald.com]
> Sent: Friday, March 17, 2017 2:53 AM
> To: Jim Richardson <j...@securit360.com>; bacula-users@lists.sourceforge.net
> Subject: Re: [Bacula-users] Dell TL1000 IBM3850-HH7
>
> Hello,
>
> First, remove all the directives you have added to the Device resource in
> your bacula-sd.conf file, and use the standard Device resource for tapes that
> is in the distributed bacula-sd.conf file. Then retry running the test. If
> you need to make changes such as the block size, ..., make the changes and
> rerun the test. If it fails, you have most likely configured something
> incorrect.
>
> If you are using the IBM tape driver, you may also have these kinds of
> problems. Make sure (lsmod) that you are using the standard Linux tape
> driver (st).
>
> Best regards,
>
> Kern
>
>
> On 03/17/2017 03:19 AM, Jim Richardson wrote:
>> I cannot seem to get my IBM3850-HH7 installed in a Dell PowerVault TL1000 to
>> pass Bacula btape test. Below is the output, I have tried every combination
>> of configuration. Below is my information. Can someone please point me to
>> a configuration that works?
>>
>> Thanks!
>>
>> =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2017.03.16 20:47:12
>> =~=~=~=~=~=~=~=~=~=~=~= btape -v /dev/stnfs0st90 Tape block
>> granularity is 1024 bytes.
>> btape: butil.c:290-0 Using device: "/dev/nst0" for writing.
>> btape: btape.c:477-0 open device &
Re: [Bacula-users] Dell TL1000 IBM3850-HH7
Good Morning,
Thank you for your response. I have done as instructed, basically where I
started off with the exact results. I am not using the IBM driver as shown
below with my lsmod results. The errors seems to be around the responses to
the FSF when Bacula is trying to reach EOF/EOT. First attempt is obviously EOT
of the medium limit shown by tapeinfo. The second is correct and attempts to
write a fourth file. After the file is written the tape is rewound, then each
file is read again, when Bacula reaches EOF of the fourth file it errors out.
What are the configuration options that control how Bacula accepts EOF/EOT? Mt
has two-fms for EOF, Bacula has several all of which I have tried. Hardware
End of Medium, Fast Forward Space File, Use MTIOCGET, BSF at EOM, Two EOM all
of which either return the same result or kick out a different error like
"reposition error". The worst part of this is that I can control the tape
drive with mt all day long with no issues. I can replicate the append
procedure using mt commands.
## bacula-sd.conf
#
# A Linux or Solaris LTO-7 tape drive
#
Device {
Name = ULT3580-HH7
Media Type = LTO-7
Archive Device = /dev/nst0
AutomaticMount = yes; # when device opened, read it
AlwaysOpen = yes;
RemovableMedia = yes;
RandomAccess = no;
# Maximum File Size = 5GB
Changer Command = "/usr/libexec/bacula/mtx-changer %c %o %S %a %d"
Changer Device = /dev/sg3
AutoChanger = yes
# # Enable the Alert command only if you have the mtx package loaded
Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'"
## If you have smartctl, enable this, it has more info than tapeinfo
## Alert Command = "sh -c 'smartctl -H -l error %c'"
}
## lsmod | grep 'st\|ibm'
dm_persistent_data 67216 1 dm_thin_pool
dm_bufio 27972 1 dm_persistent_data
dm_mod114430 68 dm_persistent_data,dm_bufio,dm_thin_pool
osst 57198 0
st 54238 2
libcrc32c 12644 2 xfs,dm_persistent_data
usb_storage66762 3 uas
Jim Richardson
-Original Message-
From: Kern Sibbald [mailto:k...@sibbald.com]
Sent: Friday, March 17, 2017 2:53 AM
To: Jim Richardson <j...@securit360.com>; bacula-users@lists.sourceforge.net
Subject: Re: [Bacula-users] Dell TL1000 IBM3850-HH7
Hello,
First, remove all the directives you have added to the Device resource in your
bacula-sd.conf file, and use the standard Device resource for tapes that is in
the distributed bacula-sd.conf file. Then retry running the test. If you need
to make changes such as the block size, ..., make the changes and rerun the
test. If it fails, you have most likely configured something incorrect.
If you are using the IBM tape driver, you may also have these kinds of
problems. Make sure (lsmod) that you are using the standard Linux tape driver
(st).
Best regards,
Kern
On 03/17/2017 03:19 AM, Jim Richardson wrote:
> I cannot seem to get my IBM3850-HH7 installed in a Dell PowerVault TL1000 to
> pass Bacula btape test. Below is the output, I have tried every combination
> of configuration. Below is my information. Can someone please point me to a
> configuration that works?
>
> Thanks!
>
> =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2017.03.16 20:47:12
> =~=~=~=~=~=~=~=~=~=~=~= btape -v /dev/stnfs0st90 Tape block
> granularity is 1024 bytes.
> btape: butil.c:290-0 Using device: "/dev/nst0" for writing.
> btape: btape.c:477-0 open device "ULT3580-HH7" (/dev/nst0): OK *test
>
> === Write, rewind, and re-read test ===
>
> I'm going to write 1 records and an EOF then write 1 records
> and an EOF, then rewind, and re-read the data to verify that it is
> correct.
>
> This is an *essential* feature ...
>
> btape: btape.c:1157-0 Wrote 1 blocks of 64412 bytes.
> btape: btape.c:609-0 Wrote 1 EOF to "ULT3580-HH7" (/dev/nst0)
> btape: btape.c:1173-0 Wrote 1 blocks of 64412 bytes.
> btape: btape.c:609-0 Wrote 1 EOF to "ULT3580-HH7" (/dev/nst0)
> btape: btape.c:1215-0 Rewind OK.
> 1 blocks re-read correctly.
> 1 blocks re-read correctly.
> === Test Succeeded. End Write, rewind, and re-read test ===
>
> btape: btape.c:1283-0 Block position test
> btape: btape.c:1295-0 Rewind OK.
> Reposition to file:block 0:4
> Block 5 re-read correctly.
> Reposition to file:block 0:200
> Block 201 re-read correctly.
> Reposition to file:block 0:
> Block 1 re-read correctly.
> Reposition to file:block 1:0
> Block 10001 re-read correctly.
> Reposition to file:block 1:600
> Block 10601 re-read correctly.
> Reposition to file:block 1:
> Block 2 re-read correctly.
> === Test Succeeded. End Write, rewind, and re-read test ===
>
>
>
>
Re: [Bacula-users] Dell TL1000 IBM3850-HH7
Hello, First, remove all the directives you have added to the Device resource in your bacula-sd.conf file, and use the standard Device resource for tapes that is in the distributed bacula-sd.conf file. Then retry running the test. If you need to make changes such as the block size, ..., make the changes and rerun the test. If it fails, you have most likely configured something incorrect. If you are using the IBM tape driver, you may also have these kinds of problems. Make sure (lsmod) that you are using the standard Linux tape driver (st). Best regards, Kern On 03/17/2017 03:19 AM, Jim Richardson wrote: > I cannot seem to get my IBM3850-HH7 installed in a Dell PowerVault TL1000 to > pass Bacula btape test. Below is the output, I have tried every combination > of configuration. Below is my information. Can someone please point me to a > configuration that works? > > Thanks! > > =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2017.03.16 20:47:12 =~=~=~=~=~=~=~=~=~=~=~= > btape -v /dev/stnfs0st90 > Tape block granularity is 1024 bytes. > btape: butil.c:290-0 Using device: "/dev/nst0" for writing. > btape: btape.c:477-0 open device "ULT3580-HH7" (/dev/nst0): OK > *test > > === Write, rewind, and re-read test === > > I'm going to write 1 records and an EOF > then write 1 records and an EOF, then rewind, > and re-read the data to verify that it is correct. > > This is an *essential* feature ... > > btape: btape.c:1157-0 Wrote 1 blocks of 64412 bytes. > btape: btape.c:609-0 Wrote 1 EOF to "ULT3580-HH7" (/dev/nst0) > btape: btape.c:1173-0 Wrote 1 blocks of 64412 bytes. > btape: btape.c:609-0 Wrote 1 EOF to "ULT3580-HH7" (/dev/nst0) > btape: btape.c:1215-0 Rewind OK. > 1 blocks re-read correctly. > 1 blocks re-read correctly. > === Test Succeeded. End Write, rewind, and re-read test === > > btape: btape.c:1283-0 Block position test > btape: btape.c:1295-0 Rewind OK. > Reposition to file:block 0:4 > Block 5 re-read correctly. > Reposition to file:block 0:200 > Block 201 re-read correctly. > Reposition to file:block 0: > Block 1 re-read correctly. > Reposition to file:block 1:0 > Block 10001 re-read correctly. > Reposition to file:block 1:600 > Block 10601 re-read correctly. > Reposition to file:block 1: > Block 2 re-read correctly. > === Test Succeeded. End Write, rewind, and re-read test === > > > > === Append files test === > > This test is essential to Bacula. > > I'm going to write one record in file 0, > two records in file 1, > and three records in file 2 > > btape: btape.c:579-0 Rewound "ULT3580-HH7" (/dev/nst0) > btape: btape.c:1914-0 Wrote one record of 64412 bytes. > btape: btape.c:1916-0 Wrote block to device. > btape: btape.c:609-0 Wrote 1 EOF to "ULT3580-HH7" (/dev/nst0) > btape: btape.c:1914-0 Wrote one record of 64412 bytes. > btape: btape.c:1916-0 Wrote block to device. > btape: btape.c:1914-0 Wrote one record of 64412 bytes. > btape: btape.c:1916-0 Wrote block to device. > btape: btape.c:609-0 Wrote 1 EOF to "ULT3580-HH7" (/dev/nst0) > btape: btape.c:1914-0 Wrote one record of 64412 bytes. > btape: btape.c:1916-0 Wrote block to device. > btape: btape.c:1914-0 Wrote one record of 64412 bytes. > btape: btape.c:1916-0 Wrote block to device. > btape: btape.c:1914-0 Wrote one record of 64412 bytes. > btape: btape.c:1916-0 Wrote block to device. > btape: btape.c:609-0 Wrote 1 EOF to "ULT3580-HH7" (/dev/nst0) > btape: btape.c:477-0 open device "ULT3580-HH7" (/dev/nst0): OK > btape: btape.c:579-0 Rewound "ULT3580-HH7" (/dev/nst0) > btape: btape.c:1427-0 Now moving to end of medium. > btape: btape.c:630-0 Moved to end of medium. > We should be in file 3. I am at file 8388607. This is NOT correct > > Append test failed. Attempting again. > Setting "Hardware End of Medium = no > and "Fast Forward Space File = no > and retrying append test. > > > > === Append files test === > > This test is essential to Bacula. > > I'm going to write one record in file 0, > two records in file 1, > and three records in file 2 > > btape: btape.c:579-0 Rewound "ULT3580-HH7" (/dev/nst0) > btape: btape.c:1914-0 Wrote one record of 64412 bytes. > btape: btape.c:1916-0 Wrote block to device. > btape: btape.c:609-0 Wrote 1 EOF to "ULT3580-HH7" (/dev/nst0) > btape: btape.c:1914-0 Wrote one record of 64412 bytes. > btape: btape.c:1916-0 Wrote block to device. > btape: btape.c:1914-0 Wrote one record of 64412 bytes. > btape: btape.c:1916-0 Wrote block to device. > btape: btape.c:609-0 Wrote 1 EOF to "ULT3580-HH7" (/dev/nst0) > btape: btape.c:1914-0 Wrote one record of 64412 bytes. > btape: btape.c:1916-0 Wrote block to device. > btape: btape.c:1914-0 Wrote one record of 64412 bytes. > btape: btape.c:1916-0 Wrote block to device. > btape: btape.c:1914-0 Wrote one record of 64412 bytes. > btape: btape.c:1916-0 Wrote block to device. > btape: btape.c:609-0 Wrote 1 EOF to "ULT3580-HH7" (/dev/nst0) > btape:
