> On Feb 28, 2015, at 1:47 AM, Kenneth D. Merry <ken_at_FreeBSD.ORG> wrote: > > On Fri, Feb 27, 2015 at 17:56:42 -0500, Dan Langille wrote: >> >>> On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry <ken_at_freebsd.org> wrote: >>> >>> On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote: >>>> >>>>> On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry <ken_at_freebsd.org> wrote: >>>>> >>>>> >>>>> I have a fairly large set of changes to the sa(4) driver and mt(1) driver >>>>> that I'm planning to commit in the near future. >>>>> >>>>> A description of the changes is here and below in this message. >>>>> >>>>> If you have tape hardware and the inclination, I'd appreciate testing and >>>>> feedback. >>>> >>>> I have a DLT 8000 and an SDLT 220. >>>> >>>> I don't have anything running current, but I have a spare machine which I could use for testing. >>>> >>>> Do you see any value is tests with that hardware? I'd be testing it via Bacula. >>>> >>>> disclosure: I'm the sysutils/bacula-* maintainer and a Bacula committer. >>>> >>> >>> Actually, yes. Bacula is a bit tricky to configure, so your trying it out >>> would be helpful if you have the time. >> >> I have been unable to test yet. I've encountered time and hardware issues. > > I know how that goes! (On both counts.) Hardware issues fixed. Now upgrading that zfsroot box from 9.2 to 10.1 RELEASE. sudo freebsd-update -r 10.1-RELEASE upgrade Then I'll grab sources, apply your 10 STABLE patches, and build world. > >> I may be able to try tomorrow. > > So I have tested building it and it does build at least. If you're able to > figure out some of the answers below, that would be great! > >>> >>> In looking at the manuals for both the SDLT 220 and the DLT 8000, they both >>> claim to support long position information for the SCSI READ POSITION >>> command. >>> >>> You can see what I'm talking about by doing: >>> >>> mt eod >>> mt status >>> >>> On my DDS-4 tape drive, this shows: >>> >>> # mt -f /dev/nsa3 status >>> Drive: sa3: <SEAGATE DAT 06240-XXX 8071> Serial Number: HJ00YWY >>> --------------------------------- >>> Mode Density Blocksize bpi Compression >>> Current: 0x26:DDS-4 1024 bytes 97000 enabled (DCLZ) >>> --------------------------------- >>> Current Driver State: at rest. >>> --------------------------------- >>> Partition: 0 Calc File Number: -1 Calc Record Number: -1 >>> Residual: 0 Reported File Number: -1 Reported Record Number: -1 >>> Flags: None >>> >>> But on an LTO-5, which will give long position information, I get: >>> >>> [root_at_doc ~]# mt status >>> Drive: sa0: <IBM ULTRIUM-HH5 E4J1> >>> --------------------------------- >>> Mode Density Blocksize bpi Compression >>> Current: 0x58:LTO-5 variable 384607 enabled (0x1) >>> --------------------------------- >>> Current Driver State: at rest. >>> --------------------------------- >>> Partition: 0 Calc File Number: 2 Calc Record Number: -1 >>> Residual: 0 Reported File Number: 2 Reported Record Number: 32373 >>> Flags: None >>> >>> That, in combination with the changes I made to the position information >>> code in the driver, mean that even the old MTIOCGET ioctl should return an >>> accurate file number at end of data. e.g., on the LTO-5: >>> >>> [root_at_doc ~]# mt ostatus >>> Mode Density Blocksize bpi Compression >>> Current: 0x58:LTO-5 variable 384607 0x1 >>> ---------available modes--------- >>> 0: 0x58:LTO-5 variable 384607 0x1 >>> 1: 0x58:LTO-5 variable 384607 0x1 >>> 2: 0x58:LTO-5 variable 384607 0x1 >>> 3: 0x58:LTO-5 variable 384607 0x1 >>> --------------------------------- >>> Current Driver State: at rest. >>> --------------------------------- >>> File Number: 2 Record Number: -1 Residual Count -1 >>> >>> So the thing to try, in addition to just making sure that Bacula continues >>> to work properly, is to try setting this for the tape drive in >>> bacula-sd.conf: >>> >>> Hardware End of Medium = yes >>> >>> It looks like the Bacula tape program (btape) has a test mode, and it would >>> be good to run through the tests on one of the tape drives and see whether >>> they work, and whether the results are different before and after the >>> changes. I'm not sure how to enable the test mode. >>> >>>> I'll let the other Bacula devs know about this. They deal with the hardware. I work on PostgreSQL. >>>> >>> >>> Thanks! If there are additional features they would like out of the tape >>> driver, I'm happy to talk about it. (Or help if they'd like to use the new >>> status reporting ioctl, MTIOCEXTGET or any of the other new ioctls.) >>> >>> Ken >>> -- >>> Kenneth Merry >>> ken_at_FreeBSD.ORG >> >> ? >> Dan Langille >> http://langille.org/ >> >> >> >> >> > > Ken > -- > Kenneth Merry > ken_at_FreeBSD.ORG — Dan Langille http://langille.org/Received on Sat Feb 28 2015 - 14:53:21 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:56 UTC