Bug 50691
| Summary: | EOT detection in sa driver prevents mutli volume dump | ||
|---|---|---|---|
| Product: | Base System | Reporter: | lkoeller <lkoeller> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | CC: | Lars.Koeller |
| Priority: | Normal | ||
| Version: | 4.8-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
On Mon, 7 Apr 2003 lkoeller@freebsd.org wrote: > >Description: > > When dumping a volume on an SCSI magnetic tape, a tape change request > leads to the abort of the dump process (dump ant tape on same machine): > ... > Note: I notice a change of the behaviour of the tape driver somehow in October > 2002. Till there a EOT of the tape was correct signaled by the driver during > writing. After there was only an error reportet and the nuber of bytes written: This was the only change in the driver between 4.7 and 4.8. %%% RCS file: /home/ncvs/src/sys/cam/scsi/scsi_sa.c,v Working file: scsi_sa.c head: 1.92 ... ---------------------------- revision 1.85 date: 2002/12/16 17:40:17; author: trhodes; state: Exp; lines: +4 -0 The HP DAT 40 tape drive should be able to handle variable block sizes. But for some reason the block size is different when a different type of tape is placed in the drive. This commit fixes that. PR: 46209 Submitted by: Alex Wang <alex@alexwang.com> Approved by: mjacob ---------------------------- %%% %%% Index: scsi_sa.c =================================================================== RCS file: /home/ncvs/src/sys/cam/scsi/scsi_sa.c,v retrieving revision 1.45.2.12 retrieving revision 1.45.2.13 diff -u -r1.45.2.12 -r1.45.2.13 --- scsi_sa.c 2 Aug 2002 06:25:56 -0000 1.45.2.12 +++ scsi_sa.c 17 Dec 2002 17:08:50 -0000 1.45.2.13 [Id change deleted] @@ -304,6 +304,10 @@ "C15*", "*"}, SA_QUIRK_VARIABLE|SA_QUIRK_NO_CPAGE, 0, }, #endif + { + { T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "HP", + "C56*", "*"}, SA_QUIRK_VARIABLE|SA_QUIRK_2FM, 0 + }, { { T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "HP", "T20*", "*"}, SA_QUIRK_FIXED|SA_QUIRK_1FM, 512 %%% Try changing the code to match the log message. The log message only claims to change to variable block sizes, but the code also sets the EOD handling and this is apparently causes changed and wrong EOD handling. The wildcards are also inconsistent with the log message. Bruce On Tue, 8 Apr 2003, Bruce Evans wrote:
> On Mon, 7 Apr 2003 lkoeller@freebsd.org wrote:
> > Note: I notice a change of the behaviour of the tape driver somehow in October
> > 2002. Till there a EOT of the tape was correct signaled by the driver during
> > writing. After there was only an error reportet and the nuber of bytes written:
>
> This was the only change in the driver between 4.7 and 4.8.
>
> ----------------------------
> revision 1.85
> date: 2002/12/16 17:40:17; author: trhodes; state: Exp; lines: +4 -0
> The HP DAT 40 tape drive should be able to handle variable block sizes.
> But for some reason the block size is different when a different type of
> tape is placed in the drive. This commit fixes that.
>
> PR: 46209
> Submitted by: Alex Wang <alex@alexwang.com>
> Approved by: mjacob
> ----------------------------
> %%%
>
> %%%
> Index: scsi_sa.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/cam/scsi/scsi_sa.c,v
> retrieving revision 1.45.2.12
> retrieving revision 1.45.2.13
> diff -u -r1.45.2.12 -r1.45.2.13
> --- scsi_sa.c 2 Aug 2002 06:25:56 -0000 1.45.2.12
> +++ scsi_sa.c 17 Dec 2002 17:08:50 -0000 1.45.2.13
> [Id change deleted]
> @@ -304,6 +304,10 @@
> "C15*", "*"}, SA_QUIRK_VARIABLE|SA_QUIRK_NO_CPAGE, 0,
> },
> #endif
> + {
> + { T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "HP",
> + "C56*", "*"}, SA_QUIRK_VARIABLE|SA_QUIRK_2FM, 0
> + },
> {
> { T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "HP",
> "T20*", "*"}, SA_QUIRK_FIXED|SA_QUIRK_1FM, 512
> %%%
I agree with Bruce. Remove the "|SA_QUIRK_2FM" from the C56 line above,
recompile your kernel, and try again. Let us know if this fixes things
for you. Variable block size has little to do with requiring 2 end of
file marks and the original commit should have been more careful about
this.
-Nate
Hi, first of all thanks for the quick replay! In reply to Nate Lawson who wrote: >> %%% >> Index: scsi_sa.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> RCS file: /home/ncvs/src/sys/cam/scsi/scsi_sa.c,v >> retrieving revision 1.45.2.12 >> retrieving revision 1.45.2.13 >> diff -u -r1.45.2.12 -r1.45.2.13 >> --- scsi_sa.c 2 Aug 2002 06:25:56 -0000 1.45.2.12 >> +++ scsi_sa.c 17 Dec 2002 17:08:50 -0000 1.45.2.13 >> [Id change deleted] >> @@ -304,6 +304,10 @@ >> "C15*", "*"}, SA_QUIRK_VARIABLE|SA_QUIRK_NO_CPAGE, 0, >> }, >> #endif >> + { >> + { T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "HP", >> + "C56*", "*"}, SA_QUIRK_VARIABLE|SA_QUIRK_2FM, 0 >> + }, >> { >> { T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "HP", >> "T20*", "*"}, SA_QUIRK_FIXED|SA_QUIRK_1FM, 512 >> %%% > >I agree with Bruce. Remove the "|SA_QUIRK_2FM" from the C56 line above,= >recompile your kernel, and try again. Let us know if this fixes things >for you. Variable block size has little to do with requiring 2 end of >file marks and the original commit should have been more careful about >this. If I understand the code change right, it is only valid for HP DAT = drives. Sorry I've forgotten to mention my is a = ARCHIVE Python 28388-XXX So this couldn't be the reason. The last successful backup on a DDS2 = and a second DDS1 tape was done at Jan 11th. So .... sorry, but I've checked both tapes tapes I've tried and both are defect! No cleaning has helped they are unusable I've never seen this before in my 8 year DAT usage: root@odie:/usr/src/sys/cam/scsi/ 129612 : mt rew root@odie:/usr/src/sys/cam/scsi/ 129613 : mt stat Mode Density Blocksize bpi Compression Current: 0x13:X3B5/88-185A variable 61000 DCLZ ---------available modes--------- 0: 0x13:X3B5/88-185A variable 61000 DCLZ 1: 0x13:X3B5/88-185A variable 61000 DCLZ 2: 0x13:X3B5/88-185A variable 61000 DCLZ 3: 0x13:X3B5/88-185A variable 61000 DCLZ --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 0 Record Number: 0 Residual Count 0 root@odie:/usr/src/sys/cam/scsi/ 129614 : tar cpv /sbin = tar: Removing leading `/' from member names sbin/ sbin/dhclient-script sbin/adjkerntz tar: /dev/nrsa0: Wrote only 0 of 10240 bytes tar: Error is not recoverable: exiting now Syslog shown: Such an error didn't come into my mind until I see the cvs diff above. So please close the PR! Thanks and best regards Lars -- = Lars K=F6ller E-Mail: lars@koellers.net (LKoeller@FreeBSD.ORG) -------- FreeBSD, was sonst? ---- http://www.de.freebsd.org -------- On Tue, 8 Apr 2003, Lars [iso-8859-1] Köller wrote:
> In reply to Nate Lawson who wrote:
>
> >I agree with Bruce. Remove the "|SA_QUIRK_2FM" from the C56 line above,
> >recompile your kernel, and try again. Let us know if this fixes things
> >for you. Variable block size has little to do with requiring 2 end of
> >file marks and the original commit should have been more careful about
> >this.
>
> If I understand the code change right, it is only valid for HP DAT
> drives. Sorry I've forgotten to mention my is a
>
> ARCHIVE Python 28388-XXX
>
> So this couldn't be the reason. The last successful backup on a DDS2
> and a second DDS1 tape was done at Jan 11th.
Please reply with the results of "camcontrol devlist" for the history of
this PR and I'll close it.
-Nate
Nate Lawson wrote: > On Tue, 8 Apr 2003, Lars [iso-8859-1] K?ller wrote: > > >In reply to Nate Lawson who wrote: > > > > > >>I agree with Bruce. Remove the "|SA_QUIRK_2FM" from the C56 line above, > >>recompile your kernel, and try again. Let us know if this fixes things > >>for you. Variable block size has little to do with requiring 2 end of > >>file marks and the original commit should have been more careful about > >>this. > > > >If I understand the code change right, it is only valid for HP DAT > >drives. Sorry I've forgotten to mention my is a > > > > ARCHIVE Python 28388-XXX > > > >So this couldn't be the reason. The last successful backup on a DDS2 > >and a second DDS1 tape was done at Jan 11th. > > > Please reply with the results of "camcontrol devlist" for the history of > this PR and I'll close it. root@odie:~/ 129660 : camcontrol devl <ARCHIVE Python 28388-XXX 5ACB> at scbus0 target 4 lun 0 (sa0,pass10) <PLEXTOR CD-ROM PX-40TS 1.04> at scbus0 target 5 lun 0 (cd0,pass11) <SEAGATE ST19101W 0014> at scbus0 target 8 lun 0 (pass0,da2) <SEAGATE ST19101W 0014> at scbus0 target 9 lun 0 (pass1,da3) <SEAGATE ST32171W 0338> at scbus0 target 10 lun 0 (pass2,da4) <IBM DCAS-34330 S61A> at scbus1 target 0 lun 0 (pass3,da0) <DEC RZ2DD-LS (C) DEC 0306> at scbus1 target 1 lun 0 (pass4,da1) <IBM DCAS-34330 S61A> at scbus1 target 2 lun 0 (pass5,da6) <IBM DNES-309170 SA30> at scbus1 target 3 lun 0 (pass6,da7) <SEAGATE ST32171W 0338> at scbus1 target 11 lun 0 (pass7,da5) <PIONEER CD-ROM DR-U10X 1.07> at scbus2 target 5 lun 0 (pass8,cd2) <PIONEER CD-ROM DR-U12X 1.06> at scbus2 target 6 lun 0 (pass9,cd3) What still has changed is the behaviour of the write command when EOT is reached. See my note in the PR. Do you have any idea for this? Best regards Lars -- Lars Köller E-Mail: lars@koellers.net (LKoeller@FreeBSD.ORG) -------- FreeBSD, was sonst? ---- http://www.de.freebsd.org -------- State Changed From-To: open->closed The write behavior should be submitted as a separate PR. Since we can't make more headway on this, I'm closing it. |
When dumping a volume on an SCSI magnetic tape, a tape change request leads to the abort of the dump process (dump ant tape on same machine): root@odie:~/ 129569 : dump -0ua /opt DUMP: Date of this level 0 dump: Mon Apr 7 14:16:21 2003 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/ccd1a (/opt) to /dev/nrsa0 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 3659849 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 12.90% done, finished in 0:33 DUMP: 19.75% done, finished in 0:40 DUMP: 26.95% done, finished in 0:40 DUMP: 34.42% done, finished in 0:38 DUMP: 39.71% done, finished in 0:37 DUMP: 45.12% done, finished in 0:36 DUMP: 50.15% done, finished in 0:34 DUMP: 53.43% done, finished in 0:34 DUMP: 57.82% done, finished in 0:32 DUMP: 61.61% done, finished in 0:31 DUMP: 64.98% done, finished in 0:29 DUMP: 70.55% done, finished in 0:25 DUMP: 75.63% done, finished in 0:20 DUMP: 82.06% done, finished in 0:15 DUMP: End of tape detected DUMP: Closing /dev/nrsa0 DUMP: Change Volumes: Mount volume #2 DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") yes DUMP: Volume 2 begins with blocks from inode 516537 DUMP: EOT detected at start of the tape! DUMP: The ENTIRE dump is aborted. The kernel reports: (sa0:ahc0:0:4:0): WRITE FILEMARKS. CDB: 10 0 0 0 2 0 (sa0:ahc0:0:4:0): DATA PROTECT asc:30,0 (sa0:ahc0:0:4:0): Incompatible medium installed (sa0:ahc0:0:4:0): failed to write terminating filemark(s) (sa0:ahc0:0:4:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state. The first tape was a 4GB DDS2 tape the second a 2GB DDS1 here are the mt output before the dump starts and during the change of the tape: root@odie:~/ 129570 : mt stat Mode Density Blocksize bpi Compression Current: 0x24:DDS-2 variable 61000 DCLZ ---------available modes--------- 0: 0x24:DDS-2 variable 61000 DCLZ 1: 0x24:DDS-2 variable 61000 DCLZ 2: 0x24:DDS-2 variable 61000 DCLZ 3: 0x24:DDS-2 variable 61000 DCLZ --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 6 Record Number: 0 Residual Count 0 root@odie:~/ 129571 : mt off root@odie:~/ 129572 : mt stat Mode Density Blocksize bpi Compression Current: 0x13:X3B5/88-185A variable 61000 DCLZ ---------available modes--------- 0: 0x13:X3B5/88-185A variable 61000 DCLZ 1: 0x13:X3B5/88-185A variable 61000 DCLZ 2: 0x13:X3B5/88-185A variable 61000 DCLZ 3: 0x13:X3B5/88-185A variable 61000 DCLZ --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 0 Record Number: 0 Residual Count 0 root@odie:~/ 129573 : mt rew At this point I enter the "yes" statement in the dump window. Before entering yes the new tape was mounted and the "mt stat" and "mt rew" succeeded. Befor the upgrade (from source) the exact same setup worked well a day before. Note: I notice a change of the behaviour of the tape driver somehow in October 2002. Till there a EOT of the tape was correct signaled by the driver during writing. After there was only an error reportet and the nuber of bytes written: Aug 24 23:57:21 door dattape: dattape: Write returned: -1 instead 1048576 Bytes. No space left on device Aug 25 21:36:35 door dattape: dattape: Write returned: -1 instead 1048576 Bytes. No space left on device Aug 25 23:54:19 door dattape: dattape: Write returned: -1 instead 1048576 Bytes. No space left on device Aug 27 21:34:08 door dattape: dattape: Write returned: -1 instead 1048576 Bytes. No space left on device Oct 6 21:48:50 door dattape: dattape: Write returned: -1 instead 1048576 Bytes. No space left on device Oct 6 23:36:47 door dattape: dattape: Write returned: -1 instead 1048576 Bytes. No space left on device Oct 21 21:37:13 door dattape: dattape: Write returned: 0 instead 1048576 Bytes. No such file or directory Oct 27 21:32:50 door dattape: dattape: Write returned: 589824 instead 1048576 Bytes. No such file or directory Oct 27 23:17:27 door dattape: dattape: Write returned: 65536 instead 1048576 Bytes. No such file or directory Nov 4 00:25:39 door dattape: dattape: Write returned: 65536 instead 1048576 Bytes. No such file or directory Nov 4 00:32:00 door dattape: dattape: Write returned: 65536 instead 1048576 Bytes. No such file or directory Nov 4 07:37:18 door dattape: dattape: Write returned: 786432 instead 1048576 Bytes. No such file or directory Nov 10 23:46:53 door dattape: dattape: Write returned: 589824 instead 1048576 Bytes. No such file or directory Nov 12 21:16:44 door dattape: dattape: Write returned: 589824 instead 1048576 Bytes. No such file or directory The logs are gerenrated by the same application without any change! Fix: Don't know How-To-Repeat: Perform a dump of a lage filesystem on more than one tape.