RE: Problems with SCSI tape rewind / verify on 2.4.29
This corrected the problem on 2.4.29. Thanks Marcelo and all for your help. Mark -Original Message- From: Marcelo Tosatti [mailto:[EMAIL PROTECTED] Sent: 02 March 2005 12:04 To: Mark Yeatman Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: Problems with SCSI tape rewind / verify on 2.4.29 On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote: > Hi > > Never had to log a bug before, hope this is correctly done. > > Thanks > > Mark > > Detail > > [1.] One line summary of the problem: > SCSI tape drive is refusing to rewind after backup to allow verify and > causing illegal seek error > > [2.] Full description of the problem/report: > On backup the tape drive is reporting the following error and failing > it's backups. > > tar: /dev/st0: Warning: Cannot seek: Illegal seek > > I have traced this back to failing at an upgrade of the kernel to 2.4.29 > on Feb 8th. The backups have not worked since. Replacement Drives have > been tried and cables to no avail. I noticed in the the changelog that a > patch by Solar Designer to the Scsi tape return code had been made. v2.6 also contains the same problem BTW. Try this: --- a/drivers/scsi/st.c.orig2005-03-02 09:02:13.637158144 -0300 +++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300 @@ -3778,7 +3778,6 @@ read: st_read, write: st_write, ioctl: st_ioctl, - llseek: no_llseek, open: st_open, flush: st_flush, release:st_release, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Problems with SCSI tape rewind / verify on 2.4.29
This corrected the problem on 2.4.29. Thanks Marcelo and all for your help. Mark -Original Message- From: Marcelo Tosatti [mailto:[EMAIL PROTECTED] Sent: 02 March 2005 12:04 To: Mark Yeatman Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: Problems with SCSI tape rewind / verify on 2.4.29 On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote: Hi Never had to log a bug before, hope this is correctly done. Thanks Mark Detail [1.] One line summary of the problem: SCSI tape drive is refusing to rewind after backup to allow verify and causing illegal seek error [2.] Full description of the problem/report: On backup the tape drive is reporting the following error and failing it's backups. tar: /dev/st0: Warning: Cannot seek: Illegal seek I have traced this back to failing at an upgrade of the kernel to 2.4.29 on Feb 8th. The backups have not worked since. Replacement Drives have been tried and cables to no avail. I noticed in the the changelog that a patch by Solar Designer to the Scsi tape return code had been made. v2.6 also contains the same problem BTW. Try this: --- a/drivers/scsi/st.c.orig2005-03-02 09:02:13.637158144 -0300 +++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300 @@ -3778,7 +3778,6 @@ read: st_read, write: st_write, ioctl: st_ioctl, - llseek: no_llseek, open: st_open, flush: st_flush, release:st_release, - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI tape rewind / verify on 2.4.29
On Wed, 2 Mar 2005, Andrew Morton wrote: > Kai Makisara <[EMAIL PROTECTED]> wrote: > > > > > > > > v2.6 also contains the same problem BTW. > > > > > > Try this: > > > > > > --- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300 > > > +++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300 > > > @@ -3778,7 +3778,6 @@ > > > read: st_read, > > > write: st_write, > > > ioctl: st_ioctl, > > > -llseek: no_llseek, > > > open: st_open, > > > flush: st_flush, > > > release:st_release, > > > > This change covers up the problem. The real bug is in tar. > > In that case we're kinda screwed, and should change the kernel to make tar > work again. We can send a bug report to the tar folks (good luck) and wait > a few years. > > > The first BSF did position the tape correctly although it did fail. > > (what's a BSF?) > > If it positioned the tape successfully, why did it claim that it failed? BSF moves the tape backwards over filemarks. tar tries to move over one filemark. It does not find it because it ends to the beginning of the tape. This is why the operation fails. However, the tape is at the beginning and this is the correct place with regard to what is done next. > If we were to fix that up, would tar then be happy? It is not fixable in the kernel. The beginning of the tape is a special case because there is no filemark. Any application should take this into account. We could fake a filemark there but this would lead to problems because then we could "skip" backwards indefinitely even when the tape moves nowhere. This could confuse other applications. If seek with tape is changed back to returning success, this would enable correct tar --verify at the beginning of the tape. However, I am not sure what happens if we are not at the beginning. I will investigate this and suggest a long term fix to the tar people (a fix that should be compatible with all Unix tape semantics I know) and also suggest possible fixes to st (this may include automatic writing of a filemark when BSF is used after writes). If you think want to make st return success for seeks even if nothing happens (as it did earlier), I don't have anything against that. It would solve the practical problem several people have reported recently. (My recommendation for the people seeing this problem is to do verification separately with 'tar -d'.) -- Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI tape rewind / verify on 2.4.29
Andrew/Kai, > List: linux-kernel > Subject: Re: Problems with SCSI tape rewind / verify on 2.4.29 > From: Andrew Morton > Date: 2005-03-02 22:17:11 > Message-ID: <20050302141711.00ec7147.akpm () osdl ! org> > [Download message RAW] > > Kai Makisara <[EMAIL PROTECTED]> wrote: > > > > f seek with tape is changed back to returning success, this would > > enable correct tar --verify at the beginning of the tape. However, > > I am not sure what happens if we are not at the beginning. I will > > investigate this and suggest a long term fix to the tar people (a > > fix that should be compatible with all Unix tape semantics I know) > > and also suggest possible fixes to st (this may include automatic > > writing of a filemark when BSF is used after writes). Kai, I have a second problem that is perhaps another case of kernel and tar combined effect problem. I have not had time to test with the 2.6.7 and 2.6.9 knoppix based kernels to see if same problem as >= 2.4.26 has. Can you hold out about 3-4 days for me to do the test and report the issue to Marcelo to screen first, Kai? I have feeling what I experienced in testing change to st.c Marcelo suggested that caused me to try 2.4.26 again and fail on this new issue has some bearing on tape positioning you want to check out. > > Yes, please let's get a tar fix in the pipeline. > > GNU tar must run on a lot of operating systems. It's odd. > > > If you think want to make st return success for seeks even if > > nothing happens (as it did earlier), I don't have anything against > > that. It would I think it is important if an error is enccountered a non-successful return (code) is returned. If an action is required that requires no action as it is at the place/state/position being requested it is reasonable to return a successful return (code). > > solve the practical problem several people have reported recently. > > (My recommendation for the people seeing this problem is to do > > verification separately with 'tar -d'.) As aside, I have tried the tar -d option as well and it worked, but was my understanding the --verify does a data readback compare of the files in the tar, whereas the tar -d option only compares if files names in tar to directory? That to me means a big difference in confidance the tar backup is ok, as I look to have readback verify to increase confidance of backup success. > > Yes, I think we need to grit our teeth and do this. I'll stick a > comment in there. Regards, John L. Males Willowdale, Ontario Canada 02 March 2005 (17:45 -) 18:51 == "Bmer ... Boom Boom, how are you Boom Boom" "Meow, meoaa" as Boomer loudly announces intent Boomer is coming for attention Loved to kneed arm and lick arm with Boomers very large tongue Able to catch, or at least hit, almost any object in flight withing reach of front paws Boomer 1985 (Born), Adopted 04 September 1991 04 September 1991 - 08 February 2000 18:50 "How are you Mr. Sylvester?" "... Grunt Grunt" ... quick licks of nose Rolls over for pet and stomac rub when Dad arrives home and grunting Runs back and forth from study, tilts head as glowing green eyes stare for "attention please", grunts and meows, repeats run, tilt head and stare few times for good measure, grunts and meows Lays on floor just outside study to guard Dad Loved to groom Miss Mahogany, and let Mahogany cuddle beside Sylvester 1989 (estimated Born) Found in building mail area noon hour 09 Feburary 1992 09 February 1992 - 19 January 2003 23:25 "Hello Miss Chicago 'White Sox', how are you 'Chico'?" "Grunt" (thank you) ... as put out food for Chicago "ME" So loud the world stops A very determined Miss "White Sox" AKA "Chico" ... Cheryl Crawford used as nickname Loved to chase kibble slid down hall floor, bat about and then eat Loved to hook paw in dish to toss out a single kibble at time, dart at as moved, then eat ... "Crunches" Chicago "White Sox", "Chico" August 1989 (born), adopted 04 February 1991 05 October 2004 06:52 Quite "Grunts" as lay Chicago on bed for last time 04 February 1991 - 05 October 2004 07:32 pgp7yXKaQLjXX.pgp Description: PGP signature
Re: Problems with SCSI tape rewind / verify on 2.4.29
Marcelo,
My couple cents worth:
> On Wed, Mar 02, 2005 at 11:17:19PM +0200, Kai Makisara wrote:
> > On Wed, 2 Mar 2005, Marcelo Tosatti wrote:
> >
> > > On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote:
> > > > Hi
> > > >
> > > > Never had to log a bug before, hope this is correctly done.
> > > >
> > > > Thanks
> > > >
> > > > Mark
> > > >
> > > > Detail
> > > >
> > > > [1.] One line summary of the problem:
> > > > SCSI tape drive is refusing to rewind after backup to allow
> > > > verify and causing illegal seek error
> > > >
> > > > [2.] Full description of the problem/report:
> > > > On backup the tape drive is reporting the following error and
> > > > failing it's backups.
> > > >
> > > > tar: /dev/st0: Warning: Cannot seek: Illegal seek
> > > >
> > > > I have traced this back to failing at an upgrade of the kernel
> > > > to 2.4.29 on Feb 8th. The backups have not worked since.
> > > > Replacement Drives have been tried and cables to no avail. I
> > > > noticed in the the changelog that a patch by Solar Designer to
> > > > the Scsi tape return code had been made.
> >
> > BTW, this "fix" by Solar Designer introduces a bug to 2.4.29: a
> > tape driver is supposed to return ENOMEM in the case that was
> > changed to return EIO ;-(
>
> Reverted.
>
> > > v2.6 also contains the same problem BTW.
> > >
> > > Try this:
> > >
> > > --- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300
> > > +++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300
> > > @@ -3778,7 +3778,6 @@
> > > read: st_read,
> > > write: st_write,
> > > ioctl: st_ioctl,
> > > - llseek: no_llseek,
> > > open: st_open,
> > > flush: st_flush,
> > > release:st_release,
> >
> > This change covers up the problem. The real bug is in tar. The
> > following code is from tar is supposed to reposition the tape to
> > the beginning of the file jus written:
> >
> > #ifdef MTIOCTOP
> > {
> > struct mtop operation;
> > int status;
> >
> > operation.mt_op = MTBSF;
> > operation.mt_count = 1;
> > if (status = rmtioctl (archive, MTIOCTOP, (char *)
> > ), status
> > < 0)
> > {
> > if (errno != EIO
> > || (status = rmtioctl (archive, MTIOCTOP, (char *)
> > ),
> > status < 0))
> > {
> > #endif
> > if (rmtlseek (archive, (off_t) 0, SEEK_SET) != 0)
> > {
> > /* Lseek failed. Try a different method. */
> > seek_warn (archive_name_array[0]);
> > return;
> > }
> > #ifdef MTIOCTOP
> > }
> > }
> > }
> > #endif
> >
> >
> > Here is output from strace showing what happens with 'tar -c -W'
> > applied at the beginning of the tape (this is using kernel
> > 2.6.11-rc4 but the same probably happens with 2.4.29):
> > ...
> > ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE,
> > 0x7fffecd0) = -1 EIO (Input/output error)
> > ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE,
> > 0x7fffecd0) = -1 EIO (Input/output error)
> > lseek(3, 0, SEEK_SET) = -1 ESPIPE (Illegal seek)
> >
> > So, both tape positioning commands fail and the code falls back to
> > lseek. Earlier it has returned success even though it has not done
> > anything (this was on purpose because it is the way some other
> > Unices behave and with reason). In that case this tar succeeded
> > but it was pure luck. The first BSF did position the tape
> > correctly although it did fail.
> >
> > The 2.6 st driver does contain this near the beginning of
> > st_open():
> >
> > nonseekable_open(inode, filp);
> >
> > This probably makes lseek fail. This code has been in st.c since
> > 2.6.8.
>
> Thanks for the cluebat Kai, is this problem fixed in newer versions
> of tar?
My testing last week or so has been with the latest tar, tar-1.15.1-2,
tar 1.14 and 1.13 had same lseek --verify issues.
>
> I suspect v2.4 should work with older versions of tar, so we should
> keep "lseek" working to make it happy. What is your opinion?
I would agree in the lseek sense. I feel that if there is some bad
behaviour in tar it should be reported to the tar folks to be fixed so
long term things are done correctly and over time the kernel
worarounds can be depreciated.
Regards
John L. Males
Willowdale, Ontario
Canada
02 March 2005 (17:04 -) 17:25
==
"Bmer ... Boom Boom, how are you Boom Boom"
"Meow, meoaa" as Boomer loudly announces
intent Boomer is coming for attention
Loved to kneed arm and lick arm with Boomers very large
tongue
Able to catch, or at least hit, almost any object in flight
withing reach of front paws
Boomer 1985 (Born), Adopted 04 September 1991
04 September 1991 - 08 February 2000 18:50
"How are you Mr. Sylvester?"
"... Grunt Grunt"
Re: Problems with SCSI tape rewind / verify on 2.4.29
Kai Makisara <[EMAIL PROTECTED]> wrote: > > f seek with tape is changed back to returning success, this would enable > correct tar --verify at the beginning of the tape. However, I am not sure > what happens if we are not at the beginning. I will investigate this and > suggest a long term fix to the tar people (a fix that should be compatible > with all Unix tape semantics I know) and also suggest possible fixes to st > (this may include automatic writing of a filemark when BSF is used after > writes). Yes, please let's get a tar fix in the pipeline. GNU tar must run on a lot of operating systems. It's odd. > If you think want to make st return success for seeks even if nothing > happens (as it did earlier), I don't have anything against that. It would > solve the practical problem several people have reported recently. (My > recommendation for the people seeing this problem is to do verification > separately with 'tar -d'.) Yes, I think we need to grit our teeth and do this. I'll stick a comment in there. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI tape rewind / verify on 2.4.29
On Wed, 2 Mar 2005, Marcelo Tosatti wrote: > On Wed, Mar 02, 2005 at 11:17:19PM +0200, Kai Makisara wrote: ... > > BTW, this "fix" by Solar Designer introduces a bug to 2.4.29: a tape > > driver is supposed to return ENOMEM in the case that was changed to return > > EIO ;-( > > Reverted. > Thanks. ... > Thanks for the cluebat Kai, is this problem fixed in newer versions of tar? > The current CVS version seems to have the same code I quoted. > I suspect v2.4 should work with older versions of tar, so we should keep > "lseek" working to make it happy. What is your opinion? > I commented this in the other reply I just sent and I don't have a clear preference. I just hope that 2.4 and 2.6 are fixed in a compatible way. -- Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI tape rewind / verify on 2.4.29
Andrew Morton wrote: (what's a BSF?) Backward space count files (man mt). -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI tape rewind / verify on 2.4.29
On Wed, Mar 02, 2005 at 11:17:19PM +0200, Kai Makisara wrote:
> On Wed, 2 Mar 2005, Marcelo Tosatti wrote:
>
> > On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote:
> > > Hi
> > >
> > > Never had to log a bug before, hope this is correctly done.
> > >
> > > Thanks
> > >
> > > Mark
> > >
> > > Detail
> > >
> > > [1.] One line summary of the problem:
> > > SCSI tape drive is refusing to rewind after backup to allow verify and
> > > causing illegal seek error
> > >
> > > [2.] Full description of the problem/report:
> > > On backup the tape drive is reporting the following error and failing
> > > it's backups.
> > >
> > > tar: /dev/st0: Warning: Cannot seek: Illegal seek
> > >
> > > I have traced this back to failing at an upgrade of the kernel to 2.4.29
> > > on Feb 8th. The backups have not worked since. Replacement Drives have
> > > been tried and cables to no avail. I noticed in the the changelog that a
> > > patch by Solar Designer to the Scsi tape return code had been made.
>
> BTW, this "fix" by Solar Designer introduces a bug to 2.4.29: a tape
> driver is supposed to return ENOMEM in the case that was changed to return
> EIO ;-(
Reverted.
> > v2.6 also contains the same problem BTW.
> >
> > Try this:
> >
> > --- a/drivers/scsi/st.c.orig2005-03-02 09:02:13.637158144 -0300
> > +++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300
> > @@ -3778,7 +3778,6 @@
> > read: st_read,
> > write: st_write,
> > ioctl: st_ioctl,
> > - llseek: no_llseek,
> > open: st_open,
> > flush: st_flush,
> > release:st_release,
>
> This change covers up the problem. The real bug is in tar. The following
> code is from tar is supposed to reposition the tape to the beginning of
> the file jus written:
>
> #ifdef MTIOCTOP
> {
> struct mtop operation;
> int status;
>
> operation.mt_op = MTBSF;
> operation.mt_count = 1;
> if (status = rmtioctl (archive, MTIOCTOP, (char *) ), status
> < 0)
> {
> if (errno != EIO
> || (status = rmtioctl (archive, MTIOCTOP, (char *)
> ),
> status < 0))
> {
> #endif
> if (rmtlseek (archive, (off_t) 0, SEEK_SET) != 0)
> {
> /* Lseek failed. Try a different method. */
> seek_warn (archive_name_array[0]);
> return;
> }
> #ifdef MTIOCTOP
> }
> }
> }
> #endif
>
>
> Here is output from strace showing what happens with 'tar -c -W' applied
> at the beginning of the tape (this is using kernel 2.6.11-rc4 but the same
> probably happens with 2.4.29):
> ...
> ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE,
> 0x7fffecd0) = -1 EIO (Input/output error)
> ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE,
> 0x7fffecd0) = -1 EIO (Input/output error)
> lseek(3, 0, SEEK_SET) = -1 ESPIPE (Illegal seek)
>
> So, both tape positioning commands fail and the code falls back to lseek.
> Earlier it has returned success even though it has not done anything (this
> was on purpose because it is the way some other Unices behave and with
> reason). In that case this tar succeeded but it was pure luck. The first
> BSF did position the tape correctly although it did fail.
>
> The 2.6 st driver does contain this near the beginning of st_open():
>
> nonseekable_open(inode, filp);
>
> This probably makes lseek fail. This code has been in st.c since 2.6.8.
Thanks for the cluebat Kai, is this problem fixed in newer versions of tar?
I suspect v2.4 should work with older versions of tar, so we should keep
"lseek" working to make it happy. What is your opinion?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI tape rewind / verify on 2.4.29
Sorry gents, Let me correct this one more time. Regards, John L. Males Willowdale, Ontario Canada 02 March 2005 16:26 ** Reply Seperator ** On (Wed) 2005-03-02 16:15:07 -0500 John L. Males wrote in Message-ID: [EMAIL PROTECTED] To: [EMAIL PROTECTED] From: John L. Males <[EMAIL PROTECTED]> Subject: Re: Re[03]: Problems with SCSI tape rewind / verify on 2.4.29 Date: Wed, 2 Mar 2005 16:15:07 -0500 > Marcelo, > > Sorry gents, seems the LKML used to handel the RE numbering in long > past when I last mailed to LKML, bit not now, so resending this > eMail to ensure goes back to orignal thread so all the eMail > discussion is in one eMail thread. > > My applogies if this caused confusion on the LKML. > > > Regards, > > John L. Males > Willowdale, Ontario > Canada > 02 March 2005 (16:06 -) 16:15 > > > ** Reply Seperator ** > > On (Wed) 2005-03-02 15:46:26 -0500 > John L. Males wrote in Message-ID: > [EMAIL PROTECTED] > > To: Marcelo Tosatti <[EMAIL PROTECTED]> > From: John L. Males <[EMAIL PROTECTED]> > Subject: Re[03]: Problems with SCSI tape rewind / verify on 2.4.29 > Date: Wed, 2 Mar 2005 15:46:26 -0500 > > > Hi Marcello, > > > > > > ** Reply Seperator ** > > > > On (Wed) 2005-03-02 11:34:41 -0300 > > Marcelo Tosatti wrote in Message-ID: > > [EMAIL PROTECTED] > > > > To: Gene Heskett <[EMAIL PROTECTED]> > > From: Marcelo Tosatti <[EMAIL PROTECTED]> > > Subject: Re: Problems with SCSI tape rewind / verify on 2.4.29 > > Date: Wed, 2 Mar 2005 11:34:41 -0300 > > > > > > > > n Wed, Mar 02, 2005 at 12:08:51PM -0500, Gene Heskett wrote: > > > > On Wednesday 02 March 2005 07:03, Marcelo Tosatti wrote: > > > > >On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote: > > > > >> Hi > > > > >> > > > > >> Never had to log a bug before, hope this is correctly done. > > > > >> > > > > >> Thanks > > > > >> > > > > >> Mark > > > > >> > > > > >> Detail > > > > >> > > > > >> [1.] One line summary of the problem: > > > > >> SCSI tape drive is refusing to rewind after backup to allow > > > > >verify> and causing illegal seek error > > > > In my experiences with this problem that I am sure is exactly the > > same issue, the tape in fact does rewind after creating the tar to > > then perfore the --verify option. The illegal see error seems to > > arise after the rewind or more correctly bsf commands may be being > > used (but not confirmed this yet, another test I need to do in few > > days). For sure the tape is positionted back. I know as I have > > also done this test with larger directories and know and have > > heard the tape take long time to naturally get back to the start > > of tar file to be able to perform the --verify option. That said > > I am using a DLT drive. Perhpas with different drivers or tape > > drivers this issue may have variations on theme and behaviour with > > net result the same error message and/or root cause. > > > > > > >> > > > > >> [2.] Full description of the problem/report: > > > > >> On backup the tape drive is reporting the following error > > > > >and> failing it's backups. > > > > >> > > > > >> tar: /dev/st0: Warning: Cannot seek: Illegal seek > > > > >> > > > > >> I have traced this back to failing at an upgrade of the > > > > >kernel to> 2.4.29 on Feb 8th. The backups have not worked > > > > >since. Replacement> Drives have been tried and cables to no > > > > >avail. I noticed in the> the changelog that a patch by Solar > > > > >Designer to the Scsi tape> return code had been made. > > > > Last kernel to work correctly in 2.4 branch was 2.4.26. Kernel > > versions 2.4.27, 2.4.28 and 2.4.29 all fail based on my experience > > with DLT SCSI based tape. > > > > > > > > > > > >v2.6 also contains the same problem BTW. > > > > > > > > > >Try this: > > > > > > > > > >--- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 > > > > >-0300+++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 > > > > >-0300@@ -3778,7 +3778,6 @@ > > > > > read: st_read, > > >
Re: Problems with SCSI tape rewind / verify on 2.4.29
Kai Makisara <[EMAIL PROTECTED]> wrote: > > > > > v2.6 also contains the same problem BTW. > > > > Try this: > > > > --- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300 > > +++ b/drivers/scsi/st.c2005-03-02 09:02:20.208159200 -0300 > > @@ -3778,7 +3778,6 @@ > >read: st_read, > >write: st_write, > >ioctl: st_ioctl, > > - llseek: no_llseek, > >open: st_open, > >flush: st_flush, > >release:st_release, > > This change covers up the problem. The real bug is in tar. In that case we're kinda screwed, and should change the kernel to make tar work again. We can send a bug report to the tar folks (good luck) and wait a few years. > The first BSF did position the tape correctly although it did fail. (what's a BSF?) If it positioned the tape successfully, why did it claim that it failed? If we were to fix that up, would tar then be happy? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI tape rewind / verify on 2.4.29
On Wed, 2 Mar 2005, Marcelo Tosatti wrote:
> On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote:
> > Hi
> >
> > Never had to log a bug before, hope this is correctly done.
> >
> > Thanks
> >
> > Mark
> >
> > Detail
> >
> > [1.] One line summary of the problem:
> > SCSI tape drive is refusing to rewind after backup to allow verify and
> > causing illegal seek error
> >
> > [2.] Full description of the problem/report:
> > On backup the tape drive is reporting the following error and failing
> > it's backups.
> >
> > tar: /dev/st0: Warning: Cannot seek: Illegal seek
> >
> > I have traced this back to failing at an upgrade of the kernel to 2.4.29
> > on Feb 8th. The backups have not worked since. Replacement Drives have
> > been tried and cables to no avail. I noticed in the the changelog that a
> > patch by Solar Designer to the Scsi tape return code had been made.
BTW, this "fix" by Solar Designer introduces a bug to 2.4.29: a tape
driver is supposed to return ENOMEM in the case that was changed to return
EIO ;-(
>
> v2.6 also contains the same problem BTW.
>
> Try this:
>
> --- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300
> +++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300
> @@ -3778,7 +3778,6 @@
> read: st_read,
> write: st_write,
> ioctl: st_ioctl,
> - llseek: no_llseek,
> open: st_open,
> flush: st_flush,
> release:st_release,
This change covers up the problem. The real bug is in tar. The following
code is from tar is supposed to reposition the tape to the beginning of
the file jus written:
#ifdef MTIOCTOP
{
struct mtop operation;
int status;
operation.mt_op = MTBSF;
operation.mt_count = 1;
if (status = rmtioctl (archive, MTIOCTOP, (char *) ), status
< 0)
{
if (errno != EIO
|| (status = rmtioctl (archive, MTIOCTOP, (char *)
),
status < 0))
{
#endif
if (rmtlseek (archive, (off_t) 0, SEEK_SET) != 0)
{
/* Lseek failed. Try a different method. */
seek_warn (archive_name_array[0]);
return;
}
#ifdef MTIOCTOP
}
}
}
#endif
Here is output from strace showing what happens with 'tar -c -W' applied
at the beginning of the tape (this is using kernel 2.6.11-rc4 but the same
probably happens with 2.4.29):
...
ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE,
0x7fffecd0) = -1 EIO (Input/output error)
ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE,
0x7fffecd0) = -1 EIO (Input/output error)
lseek(3, 0, SEEK_SET) = -1 ESPIPE (Illegal seek)
So, both tape positioning commands fail and the code falls back to lseek.
Earlier it has returned success even though it has not done anything (this
was on purpose because it is the way some other Unices behave and with
reason). In that case this tar succeeded but it was pure luck. The first
BSF did position the tape correctly although it did fail.
The 2.6 st driver does contain this near the beginning of st_open():
nonseekable_open(inode, filp);
This probably makes lseek fail. This code has been in st.c since 2.6.8.
--
Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re[03]: Problems with SCSI tape rewind / verify on 2.4.29
Marcelo, Sorry gents, seems the LKML used to handel the RE numbering in long past when I last mailed to LKML, bit not now, so resending this eMail to ensure goes back to orignal thread so all the eMail discussion is in one eMail thread. My applogies if this caused confusion on the LKML. Regards, John L. Males Willowdale, Ontario Canada 02 March 2005 (16:06 -) 16:15 ** Reply Seperator ** On (Wed) 2005-03-02 15:46:26 -0500 John L. Males wrote in Message-ID: [EMAIL PROTECTED] To: Marcelo Tosatti <[EMAIL PROTECTED]> From: John L. Males <[EMAIL PROTECTED]> Subject: Re[03]: Problems with SCSI tape rewind / verify on 2.4.29 Date: Wed, 2 Mar 2005 15:46:26 -0500 > Hi Marcello, > > > ** Reply Seperator ** > > On (Wed) 2005-03-02 11:34:41 -0300 > Marcelo Tosatti wrote in Message-ID: > [EMAIL PROTECTED] > > To: Gene Heskett <[EMAIL PROTECTED]> > From: Marcelo Tosatti <[EMAIL PROTECTED]> > Subject: Re: Problems with SCSI tape rewind / verify on 2.4.29 > Date: Wed, 2 Mar 2005 11:34:41 -0300 > > > > > n Wed, Mar 02, 2005 at 12:08:51PM -0500, Gene Heskett wrote: > > > On Wednesday 02 March 2005 07:03, Marcelo Tosatti wrote: > > > >On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote: > > > >> Hi > > > >> > > > >> Never had to log a bug before, hope this is correctly done. > > > >> > > > >> Thanks > > > >> > > > >> Mark > > > >> > > > >> Detail > > > >> > > > >> [1.] One line summary of the problem: > > > >> SCSI tape drive is refusing to rewind after backup to allow > > > >verify> and causing illegal seek error > > In my experiences with this problem that I am sure is exactly the > same issue, the tape in fact does rewind after creating the tar to > then perfore the --verify option. The illegal see error seems to > arise after the rewind or more correctly bsf commands may be being > used (but not confirmed this yet, another test I need to do in few > days). For sure the tape is positionted back. I know as I have > also done this test with larger directories and know and have heard > the tape take long time to naturally get back to the start of tar > file to be able to perform the --verify option. That said I am > using a DLT drive. Perhpas with different drivers or tape drivers > this issue may have variations on theme and behaviour with net > result the same error message and/or root cause. > > > > >> > > > >> [2.] Full description of the problem/report: > > > >> On backup the tape drive is reporting the following error and > > > >> failing it's backups. > > > >> > > > >> tar: /dev/st0: Warning: Cannot seek: Illegal seek > > > >> > > > >> I have traced this back to failing at an upgrade of the > > > >kernel to> 2.4.29 on Feb 8th. The backups have not worked > > > >since. Replacement> Drives have been tried and cables to no > > > >avail. I noticed in the> the changelog that a patch by Solar > > > >Designer to the Scsi tape> return code had been made. > > Last kernel to work correctly in 2.4 branch was 2.4.26. Kernel > versions 2.4.27, 2.4.28 and 2.4.29 all fail based on my experience > with DLT SCSI based tape. > > > > > > > > >v2.6 also contains the same problem BTW. > > > > > > > >Try this: > > > > > > > >--- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 > > > >-0300+++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 > > > >-0300@@ -3778,7 +3778,6 @@ > > > > read: st_read, > > > > write: st_write, > > > > ioctl: st_ioctl, > > > >- llseek: no_llseek, > > > > open: st_open, > > > > flush: st_flush, > > > > release: st_release, > > > >- > > > > > > Interesting Marcelo. How long has this been true in 2.6? > > In the 2.6 tree the tar --verify works with 2.6.7, but fails with > 2.6.9. I am unable to test 2.6.8, but based on research of the code > changes of 2.6.8 compared to the changes made in 2.4.27 re llseek I > would expect 2.6.8 to fail as well with my DLT SCSI tape. > > > > > Actually I just checked and it seems v2.6 is not using > > "no_llseek". > > > > However John L. Males reports the same problem with v2.6 - John, > > care to retest with v2.6.10 ? > > My ability to test a 2.6.x kernel is limited to what 2.6.x kerne
Re[03]: Problems with SCSI tape rewind / verify on 2.4.29
Hi Marcello, ** Reply Seperator ** On (Wed) 2005-03-02 11:34:41 -0300 Marcelo Tosatti wrote in Message-ID: [EMAIL PROTECTED] To: Gene Heskett <[EMAIL PROTECTED]> From: Marcelo Tosatti <[EMAIL PROTECTED]> Subject: Re: Problems with SCSI tape rewind / verify on 2.4.29 Date: Wed, 2 Mar 2005 11:34:41 -0300 > > n Wed, Mar 02, 2005 at 12:08:51PM -0500, Gene Heskett wrote: > > On Wednesday 02 March 2005 07:03, Marcelo Tosatti wrote: > > >On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote: > > >> Hi > > >> > > >> Never had to log a bug before, hope this is correctly done. > > >> > > >> Thanks > > >> > > >> Mark > > >> > > >> Detail > > >> > > >> [1.] One line summary of the problem: > > >> SCSI tape drive is refusing to rewind after backup to allow > > >verify> and causing illegal seek error In my experiences with this problem that I am sure is exactly the same issue, the tape in fact does rewind after creating the tar to then perfore the --verify option. The illegal see error seems to arise after the rewind or more correctly bsf commands may be being used (but not confirmed this yet, another test I need to do in few days). For sure the tape is positionted back. I know as I have also done this test with larger directories and know and have heard the tape take long time to naturally get back to the start of tar file to be able to perform the --verify option. That said I am using a DLT drive. Perhpas with different drivers or tape drivers this issue may have variations on theme and behaviour with net result the same error message and/or root cause. > > >> > > >> [2.] Full description of the problem/report: > > >> On backup the tape drive is reporting the following error and > > >> failing it's backups. > > >> > > >> tar: /dev/st0: Warning: Cannot seek: Illegal seek > > >> > > >> I have traced this back to failing at an upgrade of the kernel > > >to> 2.4.29 on Feb 8th. The backups have not worked since. > > >Replacement> Drives have been tried and cables to no avail. I > > >noticed in the> the changelog that a patch by Solar Designer to > > >the Scsi tape> return code had been made. Last kernel to work correctly in 2.4 branch was 2.4.26. Kernel versions 2.4.27, 2.4.28 and 2.4.29 all fail based on my experience with DLT SCSI based tape. > > > > > >v2.6 also contains the same problem BTW. > > > > > >Try this: > > > > > >--- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300 > > >+++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300 > > >@@ -3778,7 +3778,6 @@ > > > read: st_read, > > > write: st_write, > > > ioctl: st_ioctl, > > >- llseek: no_llseek, > > > open: st_open, > > > flush: st_flush, > > > release: st_release, > > >- > > > > Interesting Marcelo. How long has this been true in 2.6? In the 2.6 tree the tar --verify works with 2.6.7, but fails with 2.6.9. I am unable to test 2.6.8, but based on research of the code changes of 2.6.8 compared to the changes made in 2.4.27 re llseek I would expect 2.6.8 to fail as well with my DLT SCSI tape. > > Actually I just checked and it seems v2.6 is not using "no_llseek". > > However John L. Males reports the same problem with v2.6 - John, > care to retest with v2.6.10 ? My ability to test a 2.6.x kernel is limited to what 2.6.x kernel I can find on a livecd. The 2.6.7 and 2.6.9 kernel tests I conducted were using Knoppix 3.6 and 3.7. I do not have means at this time, nor time, to build up a dedicated drive to test 2.6.x kernels. If someone knows of or can build a 2.6.10 kernel on a live CD I will be happy to do the test. That said, I looked at the patch for 2.6.10 and seems alot of changes were made to st.c in 2.6.10. I did not see, but could of missed in looking, any lseek related change in 2.6.10. Given how it seems the test I ran with the change in st.c Marcell suggested what is the expected thought on this issue with 2.6.10? I am just asking from curiousity. Again, if someone can tell me of a live cd or can easly make a live cd with the 2.6.10 kernel I can test this issue wiht 2.6.10. Perhaps there is someone else with a DLT/SCSI tape driver that could test this tar --verify issue on 2.6.10? > > > I thought I had an amanda problem, and eventually went to virtual > > tapes on disk, largely because of this. However, I have to say it > > is working better than tapes ever did here. Unforch, that 200GB > > disk is certainly a single point of failu
Re: Problems with SCSI tape rewind / verify on 2.4.29
n Wed, Mar 02, 2005 at 12:08:51PM -0500, Gene Heskett wrote: > On Wednesday 02 March 2005 07:03, Marcelo Tosatti wrote: > >On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote: > >> Hi > >> > >> Never had to log a bug before, hope this is correctly done. > >> > >> Thanks > >> > >> Mark > >> > >> Detail > >> > >> [1.] One line summary of the problem: > >> SCSI tape drive is refusing to rewind after backup to allow verify > >> and causing illegal seek error > >> > >> [2.] Full description of the problem/report: > >> On backup the tape drive is reporting the following error and > >> failing it's backups. > >> > >> tar: /dev/st0: Warning: Cannot seek: Illegal seek > >> > >> I have traced this back to failing at an upgrade of the kernel to > >> 2.4.29 on Feb 8th. The backups have not worked since. Replacement > >> Drives have been tried and cables to no avail. I noticed in the > >> the changelog that a patch by Solar Designer to the Scsi tape > >> return code had been made. > > > >v2.6 also contains the same problem BTW. > > > >Try this: > > > >--- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300 > >+++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300 > >@@ -3778,7 +3778,6 @@ > > read: st_read, > > write: st_write, > > ioctl: st_ioctl, > >- llseek: no_llseek, > > open: st_open, > > flush: st_flush, > > release: st_release, > >- > > Interesting Marcelo. How long has this been true in 2.6? Actually I just checked and it seems v2.6 is not using "no_llseek". However John L. Males reports the same problem with v2.6 - John, care to retest with v2.6.10 ? > I thought I had an amanda problem, and eventually went to virtual > tapes on disk, largely because of this. However, I have to say it is > working better than tapes ever did here. Unforch, that 200GB disk is > certainly a single point of failure I don't relish thinking about... :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI tape rewind / verify on 2.4.29
On Wednesday 02 March 2005 07:03, Marcelo Tosatti wrote: >On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote: >> Hi >> >> Never had to log a bug before, hope this is correctly done. >> >> Thanks >> >> Mark >> >> Detail >> >> [1.] One line summary of the problem: >> SCSI tape drive is refusing to rewind after backup to allow verify >> and causing illegal seek error >> >> [2.] Full description of the problem/report: >> On backup the tape drive is reporting the following error and >> failing it's backups. >> >> tar: /dev/st0: Warning: Cannot seek: Illegal seek >> >> I have traced this back to failing at an upgrade of the kernel to >> 2.4.29 on Feb 8th. The backups have not worked since. Replacement >> Drives have been tried and cables to no avail. I noticed in the >> the changelog that a patch by Solar Designer to the Scsi tape >> return code had been made. > >v2.6 also contains the same problem BTW. > >Try this: > >--- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300 >+++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300 >@@ -3778,7 +3778,6 @@ > read: st_read, > write: st_write, > ioctl: st_ioctl, >- llseek: no_llseek, > open: st_open, > flush: st_flush, > release: st_release, >- Interesting Marcelo. How long has this been true in 2.6? I thought I had an amanda problem, and eventually went to virtual tapes on disk, largely because of this. However, I have to say it is working better than tapes ever did here. Unforch, that 200GB disk is certainly a single point of failure I don't relish thinking about... >To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Problems with SCSI tape rewind / verify on 2.4.29
Hi Many Thanks Marcelo, the patch has corrected the fault in our 2.4.29 kernel. Mark -Original Message- From: Marcelo Tosatti [mailto:[EMAIL PROTECTED] Sent: 02 March 2005 12:04 To: Mark Yeatman Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: Problems with SCSI tape rewind / verify on 2.4.29 On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote: > Hi > > Never had to log a bug before, hope this is correctly done. > > Thanks > > Mark > > Detail > > [1.] One line summary of the problem: > SCSI tape drive is refusing to rewind after backup to allow verify and > causing illegal seek error > > [2.] Full description of the problem/report: > On backup the tape drive is reporting the following error and failing > it's backups. > > tar: /dev/st0: Warning: Cannot seek: Illegal seek > > I have traced this back to failing at an upgrade of the kernel to 2.4.29 > on Feb 8th. The backups have not worked since. Replacement Drives have > been tried and cables to no avail. I noticed in the the changelog that a > patch by Solar Designer to the Scsi tape return code had been made. v2.6 also contains the same problem BTW. Try this: --- a/drivers/scsi/st.c.orig2005-03-02 09:02:13.637158144 -0300 +++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300 @@ -3778,7 +3778,6 @@ read: st_read, write: st_write, ioctl: st_ioctl, - llseek: no_llseek, open: st_open, flush: st_flush, release:st_release, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI tape rewind / verify on 2.4.29
On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote: > Hi > > Never had to log a bug before, hope this is correctly done. > > Thanks > > Mark > > Detail > > [1.] One line summary of the problem: > SCSI tape drive is refusing to rewind after backup to allow verify and > causing illegal seek error > > [2.] Full description of the problem/report: > On backup the tape drive is reporting the following error and failing > it's backups. > > tar: /dev/st0: Warning: Cannot seek: Illegal seek > > I have traced this back to failing at an upgrade of the kernel to 2.4.29 > on Feb 8th. The backups have not worked since. Replacement Drives have > been tried and cables to no avail. I noticed in the the changelog that a > patch by Solar Designer to the Scsi tape return code had been made. v2.6 also contains the same problem BTW. Try this: --- a/drivers/scsi/st.c.orig2005-03-02 09:02:13.637158144 -0300 +++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300 @@ -3778,7 +3778,6 @@ read: st_read, write: st_write, ioctl: st_ioctl, - llseek: no_llseek, open: st_open, flush: st_flush, release:st_release, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problems with SCSI tape rewind / verify on 2.4.29
Hi Never had to log a bug before, hope this is correctly done. Thanks Mark Detail [1.] One line summary of the problem: SCSI tape drive is refusing to rewind after backup to allow verify and causing illegal seek error [2.] Full description of the problem/report: On backup the tape drive is reporting the following error and failing it's backups. tar: /dev/st0: Warning: Cannot seek: Illegal seek I have traced this back to failing at an upgrade of the kernel to 2.4.29 on Feb 8th. The backups have not worked since. Replacement Drives have been tried and cables to no avail. I noticed in the the changelog that a patch by Solar Designer to the Scsi tape return code had been made. Solar Designer: o Fix SCSI tape driver return code The tape appears to back up correctly but will not verify. [3.] Keywords (i.e., modules, networking, kernel): Solar Designer, Tape, Scsi, 2.4.29 [4.] Kernel version (from /proc/version): Linux version 2.4.29-vs1.2.10 ([EMAIL PROTECTED]) (gcc version 3.2.3) #1 SMP Tue Feb 8 15:55:58 UTC 2005 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) [6.] A small shell script or example program which triggers the problem (if possible) tar cf /dev/st0 -W -P --exclude proc --exclude dev / 1>> /var/log/backup.log 2>>/var/log/backup.log [7.] Environment [7.1.] Software (add the output of the ver_linux script here) Linux raptor 2.4.29-vs1.2.10 #1 SMP Tue Feb 8 15:55:58 UTC 2005 i686 unknown unk nown GNU/Linux Gnu C 3.2.3 Gnu make 3.80 util-linux 2.12 mount 2.12 modutils 2.4.25 e2fsprogs 1.34 Linux C Library2.3.2 Dynamic linker (ldd) 2.3.2 Linux C++ Library 5.0.3 Procps 2.0.16 Net-tools 1.60 Kbd1.08 Sh-utils 5.0 Modules Loaded [7.2.] Processor information (from /proc/cpuinfo): processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.06GHz stepping: 7 cpu MHz : 3059.270 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid bogomips: 6107.95 processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.06GHz stepping: 7 cpu MHz : 3059.270 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid bogomips: 6107.95 [7.3.] Module information (from /proc/modules): No output from here. [7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 01f0-01f7 : ide0 03c0-03df : vga+ 03f6-03f6 : ide0 0cf8-0cff : PCI conf1 a800-a8ff : Adaptec ASC-29320 U320 b000-b0ff : Adaptec ASC-29320 U320 b400-b4ff : Adaptec ASC-29320 U320 (#2) b800-b8ff : Adaptec ASC-29320 U320 (#2) bc00-bc3f : PCI device 8086:1050 (Intel Corp.) bc00-bc3f : e100 c400-c41f : Intel Corp. 82801EB SMBus Controller c800-c81f : Intel Corp. 82801EB USB cc00-cc1f : Intel Corp. 82801EB USB d000-d01f : Intel Corp. 82801EB USB d400-d41f : Intel Corp. 82801EB USB d800-d80f : Intel Corp. 82801EB Ultra ATA Storage Controller dc00-dc03 : Intel Corp. 82801EB Ultra ATA Storage Controller e000-e007 : Intel Corp. 82801EB Ultra ATA Storage Controller e400-e403 : Intel Corp. 82801EB Ultra ATA Storage Controller e800-e807 : Intel Corp. 82801EB Ultra ATA Storage Controller ec00-ec07 : Intel Corp. 82865G Integrated Graphics Device ffa0-ffaf : Intel Corp. 82801EB Ultra ATA Storage Controller -0009fbff : System RAM 0009fc00-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000ca000-000d39ff : Extension ROM 000f-000f : System ROM 0010-7ef2fbff : System RAM 0010-002b9f80 : Kernel code 002b9f81-00354667 : Kernel data 7ef2fc00-7ef2 : ACPI Non-volatile Storage 7ef3-7ef3 : ACPI Tables 7ef4-7efe : ACPI Non-volatile Storage 7eff-7eff : reserved 7f00-7f0003ff : Intel Corp. 82801EB Ultra ATA Storage Controller f000-f7ff : Intel Corp. 82865G Integrated Graphics Device f800-fbff : Intel Corp. 82865G/PE/P Processor to I/O Controller fecf-fecf0fff : reserved
Problems with SCSI tape rewind / verify on 2.4.29
Hi Never had to log a bug before, hope this is correctly done. Thanks Mark Detail [1.] One line summary of the problem: SCSI tape drive is refusing to rewind after backup to allow verify and causing illegal seek error [2.] Full description of the problem/report: On backup the tape drive is reporting the following error and failing it's backups. tar: /dev/st0: Warning: Cannot seek: Illegal seek I have traced this back to failing at an upgrade of the kernel to 2.4.29 on Feb 8th. The backups have not worked since. Replacement Drives have been tried and cables to no avail. I noticed in the the changelog that a patch by Solar Designer to the Scsi tape return code had been made. Solar Designer: o Fix SCSI tape driver return code The tape appears to back up correctly but will not verify. [3.] Keywords (i.e., modules, networking, kernel): Solar Designer, Tape, Scsi, 2.4.29 [4.] Kernel version (from /proc/version): Linux version 2.4.29-vs1.2.10 ([EMAIL PROTECTED]) (gcc version 3.2.3) #1 SMP Tue Feb 8 15:55:58 UTC 2005 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) [6.] A small shell script or example program which triggers the problem (if possible) tar cf /dev/st0 -W -P --exclude proc --exclude dev / 1 /var/log/backup.log 2/var/log/backup.log [7.] Environment [7.1.] Software (add the output of the ver_linux script here) Linux raptor 2.4.29-vs1.2.10 #1 SMP Tue Feb 8 15:55:58 UTC 2005 i686 unknown unk nown GNU/Linux Gnu C 3.2.3 Gnu make 3.80 util-linux 2.12 mount 2.12 modutils 2.4.25 e2fsprogs 1.34 Linux C Library2.3.2 Dynamic linker (ldd) 2.3.2 Linux C++ Library 5.0.3 Procps 2.0.16 Net-tools 1.60 Kbd1.08 Sh-utils 5.0 Modules Loaded [7.2.] Processor information (from /proc/cpuinfo): processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.06GHz stepping: 7 cpu MHz : 3059.270 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid bogomips: 6107.95 processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.06GHz stepping: 7 cpu MHz : 3059.270 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid bogomips: 6107.95 [7.3.] Module information (from /proc/modules): No output from here. [7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 01f0-01f7 : ide0 03c0-03df : vga+ 03f6-03f6 : ide0 0cf8-0cff : PCI conf1 a800-a8ff : Adaptec ASC-29320 U320 b000-b0ff : Adaptec ASC-29320 U320 b400-b4ff : Adaptec ASC-29320 U320 (#2) b800-b8ff : Adaptec ASC-29320 U320 (#2) bc00-bc3f : PCI device 8086:1050 (Intel Corp.) bc00-bc3f : e100 c400-c41f : Intel Corp. 82801EB SMBus Controller c800-c81f : Intel Corp. 82801EB USB cc00-cc1f : Intel Corp. 82801EB USB d000-d01f : Intel Corp. 82801EB USB d400-d41f : Intel Corp. 82801EB USB d800-d80f : Intel Corp. 82801EB Ultra ATA Storage Controller dc00-dc03 : Intel Corp. 82801EB Ultra ATA Storage Controller e000-e007 : Intel Corp. 82801EB Ultra ATA Storage Controller e400-e403 : Intel Corp. 82801EB Ultra ATA Storage Controller e800-e807 : Intel Corp. 82801EB Ultra ATA Storage Controller ec00-ec07 : Intel Corp. 82865G Integrated Graphics Device ffa0-ffaf : Intel Corp. 82801EB Ultra ATA Storage Controller -0009fbff : System RAM 0009fc00-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000ca000-000d39ff : Extension ROM 000f-000f : System ROM 0010-7ef2fbff : System RAM 0010-002b9f80 : Kernel code 002b9f81-00354667 : Kernel data 7ef2fc00-7ef2 : ACPI Non-volatile Storage 7ef3-7ef3 : ACPI Tables 7ef4-7efe : ACPI Non-volatile Storage 7eff-7eff : reserved 7f00-7f0003ff : Intel Corp. 82801EB Ultra ATA Storage Controller f000-f7ff : Intel Corp. 82865G Integrated Graphics Device f800-fbff : Intel Corp. 82865G/PE/P Processor to I/O Controller fecf-fecf0fff : reserved
Re: Problems with SCSI tape rewind / verify on 2.4.29
On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote: Hi Never had to log a bug before, hope this is correctly done. Thanks Mark Detail [1.] One line summary of the problem: SCSI tape drive is refusing to rewind after backup to allow verify and causing illegal seek error [2.] Full description of the problem/report: On backup the tape drive is reporting the following error and failing it's backups. tar: /dev/st0: Warning: Cannot seek: Illegal seek I have traced this back to failing at an upgrade of the kernel to 2.4.29 on Feb 8th. The backups have not worked since. Replacement Drives have been tried and cables to no avail. I noticed in the the changelog that a patch by Solar Designer to the Scsi tape return code had been made. v2.6 also contains the same problem BTW. Try this: --- a/drivers/scsi/st.c.orig2005-03-02 09:02:13.637158144 -0300 +++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300 @@ -3778,7 +3778,6 @@ read: st_read, write: st_write, ioctl: st_ioctl, - llseek: no_llseek, open: st_open, flush: st_flush, release:st_release, - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Problems with SCSI tape rewind / verify on 2.4.29
Hi Many Thanks Marcelo, the patch has corrected the fault in our 2.4.29 kernel. Mark -Original Message- From: Marcelo Tosatti [mailto:[EMAIL PROTECTED] Sent: 02 March 2005 12:04 To: Mark Yeatman Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: Problems with SCSI tape rewind / verify on 2.4.29 On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote: Hi Never had to log a bug before, hope this is correctly done. Thanks Mark Detail [1.] One line summary of the problem: SCSI tape drive is refusing to rewind after backup to allow verify and causing illegal seek error [2.] Full description of the problem/report: On backup the tape drive is reporting the following error and failing it's backups. tar: /dev/st0: Warning: Cannot seek: Illegal seek I have traced this back to failing at an upgrade of the kernel to 2.4.29 on Feb 8th. The backups have not worked since. Replacement Drives have been tried and cables to no avail. I noticed in the the changelog that a patch by Solar Designer to the Scsi tape return code had been made. v2.6 also contains the same problem BTW. Try this: --- a/drivers/scsi/st.c.orig2005-03-02 09:02:13.637158144 -0300 +++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300 @@ -3778,7 +3778,6 @@ read: st_read, write: st_write, ioctl: st_ioctl, - llseek: no_llseek, open: st_open, flush: st_flush, release:st_release, - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI tape rewind / verify on 2.4.29
On Wednesday 02 March 2005 07:03, Marcelo Tosatti wrote: On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote: Hi Never had to log a bug before, hope this is correctly done. Thanks Mark Detail [1.] One line summary of the problem: SCSI tape drive is refusing to rewind after backup to allow verify and causing illegal seek error [2.] Full description of the problem/report: On backup the tape drive is reporting the following error and failing it's backups. tar: /dev/st0: Warning: Cannot seek: Illegal seek I have traced this back to failing at an upgrade of the kernel to 2.4.29 on Feb 8th. The backups have not worked since. Replacement Drives have been tried and cables to no avail. I noticed in the the changelog that a patch by Solar Designer to the Scsi tape return code had been made. v2.6 also contains the same problem BTW. Try this: --- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300 +++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300 @@ -3778,7 +3778,6 @@ read: st_read, write: st_write, ioctl: st_ioctl, - llseek: no_llseek, open: st_open, flush: st_flush, release: st_release, - Interesting Marcelo. How long has this been true in 2.6? I thought I had an amanda problem, and eventually went to virtual tapes on disk, largely because of this. However, I have to say it is working better than tapes ever did here. Unforch, that 200GB disk is certainly a single point of failure I don't relish thinking about... To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI tape rewind / verify on 2.4.29
n Wed, Mar 02, 2005 at 12:08:51PM -0500, Gene Heskett wrote: On Wednesday 02 March 2005 07:03, Marcelo Tosatti wrote: On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote: Hi Never had to log a bug before, hope this is correctly done. Thanks Mark Detail [1.] One line summary of the problem: SCSI tape drive is refusing to rewind after backup to allow verify and causing illegal seek error [2.] Full description of the problem/report: On backup the tape drive is reporting the following error and failing it's backups. tar: /dev/st0: Warning: Cannot seek: Illegal seek I have traced this back to failing at an upgrade of the kernel to 2.4.29 on Feb 8th. The backups have not worked since. Replacement Drives have been tried and cables to no avail. I noticed in the the changelog that a patch by Solar Designer to the Scsi tape return code had been made. v2.6 also contains the same problem BTW. Try this: --- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300 +++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300 @@ -3778,7 +3778,6 @@ read: st_read, write: st_write, ioctl: st_ioctl, - llseek: no_llseek, open: st_open, flush: st_flush, release: st_release, - Interesting Marcelo. How long has this been true in 2.6? Actually I just checked and it seems v2.6 is not using no_llseek. However John L. Males reports the same problem with v2.6 - John, care to retest with v2.6.10 ? I thought I had an amanda problem, and eventually went to virtual tapes on disk, largely because of this. However, I have to say it is working better than tapes ever did here. Unforch, that 200GB disk is certainly a single point of failure I don't relish thinking about... :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re[03]: Problems with SCSI tape rewind / verify on 2.4.29
Hi Marcello, ** Reply Seperator ** On (Wed) 2005-03-02 11:34:41 -0300 Marcelo Tosatti wrote in Message-ID: [EMAIL PROTECTED] To: Gene Heskett [EMAIL PROTECTED] From: Marcelo Tosatti [EMAIL PROTECTED] Subject: Re: Problems with SCSI tape rewind / verify on 2.4.29 Date: Wed, 2 Mar 2005 11:34:41 -0300 n Wed, Mar 02, 2005 at 12:08:51PM -0500, Gene Heskett wrote: On Wednesday 02 March 2005 07:03, Marcelo Tosatti wrote: On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote: Hi Never had to log a bug before, hope this is correctly done. Thanks Mark Detail [1.] One line summary of the problem: SCSI tape drive is refusing to rewind after backup to allow verify and causing illegal seek error In my experiences with this problem that I am sure is exactly the same issue, the tape in fact does rewind after creating the tar to then perfore the --verify option. The illegal see error seems to arise after the rewind or more correctly bsf commands may be being used (but not confirmed this yet, another test I need to do in few days). For sure the tape is positionted back. I know as I have also done this test with larger directories and know and have heard the tape take long time to naturally get back to the start of tar file to be able to perform the --verify option. That said I am using a DLT drive. Perhpas with different drivers or tape drivers this issue may have variations on theme and behaviour with net result the same error message and/or root cause. [2.] Full description of the problem/report: On backup the tape drive is reporting the following error and failing it's backups. tar: /dev/st0: Warning: Cannot seek: Illegal seek I have traced this back to failing at an upgrade of the kernel to 2.4.29 on Feb 8th. The backups have not worked since. Replacement Drives have been tried and cables to no avail. I noticed in the the changelog that a patch by Solar Designer to the Scsi tape return code had been made. Last kernel to work correctly in 2.4 branch was 2.4.26. Kernel versions 2.4.27, 2.4.28 and 2.4.29 all fail based on my experience with DLT SCSI based tape. v2.6 also contains the same problem BTW. Try this: --- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300 +++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300 @@ -3778,7 +3778,6 @@ read: st_read, write: st_write, ioctl: st_ioctl, - llseek: no_llseek, open: st_open, flush: st_flush, release: st_release, - Interesting Marcelo. How long has this been true in 2.6? In the 2.6 tree the tar --verify works with 2.6.7, but fails with 2.6.9. I am unable to test 2.6.8, but based on research of the code changes of 2.6.8 compared to the changes made in 2.4.27 re llseek I would expect 2.6.8 to fail as well with my DLT SCSI tape. Actually I just checked and it seems v2.6 is not using no_llseek. However John L. Males reports the same problem with v2.6 - John, care to retest with v2.6.10 ? My ability to test a 2.6.x kernel is limited to what 2.6.x kernel I can find on a livecd. The 2.6.7 and 2.6.9 kernel tests I conducted were using Knoppix 3.6 and 3.7. I do not have means at this time, nor time, to build up a dedicated drive to test 2.6.x kernels. If someone knows of or can build a 2.6.10 kernel on a live CD I will be happy to do the test. That said, I looked at the patch for 2.6.10 and seems alot of changes were made to st.c in 2.6.10. I did not see, but could of missed in looking, any lseek related change in 2.6.10. Given how it seems the test I ran with the change in st.c Marcell suggested what is the expected thought on this issue with 2.6.10? I am just asking from curiousity. Again, if someone can tell me of a live cd or can easly make a live cd with the 2.6.10 kernel I can test this issue wiht 2.6.10. Perhaps there is someone else with a DLT/SCSI tape driver that could test this tar --verify issue on 2.6.10? I thought I had an amanda problem, and eventually went to virtual tapes on disk, largely because of this. However, I have to say it is working better than tapes ever did here. Unforch, that 200GB disk is certainly a single point of failure I don't relish thinking about... :) Regards, John L. Males Willowdale, Ontario Canada 02 March 2005 (15:00 -) 15:46 == Bmer ... Boom Boom, how are you Boom Boom Meow, meoaa as Boomer loudly announces intent Boomer is coming for attention Loved to kneed arm and lick arm with Boomers very large tongue Able to catch, or at least hit, almost any object in flight withing reach of front paws Boomer 1985 (Born), Adopted 04 September 1991 04 September 1991 - 08 February 2000 18:50 How are you Mr. Sylvester? ... Grunt Grunt ... quick licks of nose Rolls over for pet and stomac rub when Dad arrives home
Re: Re[03]: Problems with SCSI tape rewind / verify on 2.4.29
Marcelo, Sorry gents, seems the LKML used to handel the RE numbering in long past when I last mailed to LKML, bit not now, so resending this eMail to ensure goes back to orignal thread so all the eMail discussion is in one eMail thread. My applogies if this caused confusion on the LKML. Regards, John L. Males Willowdale, Ontario Canada 02 March 2005 (16:06 -) 16:15 ** Reply Seperator ** On (Wed) 2005-03-02 15:46:26 -0500 John L. Males wrote in Message-ID: [EMAIL PROTECTED] To: Marcelo Tosatti [EMAIL PROTECTED] From: John L. Males [EMAIL PROTECTED] Subject: Re[03]: Problems with SCSI tape rewind / verify on 2.4.29 Date: Wed, 2 Mar 2005 15:46:26 -0500 Hi Marcello, ** Reply Seperator ** On (Wed) 2005-03-02 11:34:41 -0300 Marcelo Tosatti wrote in Message-ID: [EMAIL PROTECTED] To: Gene Heskett [EMAIL PROTECTED] From: Marcelo Tosatti [EMAIL PROTECTED] Subject: Re: Problems with SCSI tape rewind / verify on 2.4.29 Date: Wed, 2 Mar 2005 11:34:41 -0300 n Wed, Mar 02, 2005 at 12:08:51PM -0500, Gene Heskett wrote: On Wednesday 02 March 2005 07:03, Marcelo Tosatti wrote: On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote: Hi Never had to log a bug before, hope this is correctly done. Thanks Mark Detail [1.] One line summary of the problem: SCSI tape drive is refusing to rewind after backup to allow verify and causing illegal seek error In my experiences with this problem that I am sure is exactly the same issue, the tape in fact does rewind after creating the tar to then perfore the --verify option. The illegal see error seems to arise after the rewind or more correctly bsf commands may be being used (but not confirmed this yet, another test I need to do in few days). For sure the tape is positionted back. I know as I have also done this test with larger directories and know and have heard the tape take long time to naturally get back to the start of tar file to be able to perform the --verify option. That said I am using a DLT drive. Perhpas with different drivers or tape drivers this issue may have variations on theme and behaviour with net result the same error message and/or root cause. [2.] Full description of the problem/report: On backup the tape drive is reporting the following error and failing it's backups. tar: /dev/st0: Warning: Cannot seek: Illegal seek I have traced this back to failing at an upgrade of the kernel to 2.4.29 on Feb 8th. The backups have not worked since. Replacement Drives have been tried and cables to no avail. I noticed in the the changelog that a patch by Solar Designer to the Scsi tape return code had been made. Last kernel to work correctly in 2.4 branch was 2.4.26. Kernel versions 2.4.27, 2.4.28 and 2.4.29 all fail based on my experience with DLT SCSI based tape. v2.6 also contains the same problem BTW. Try this: --- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300+++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300@@ -3778,7 +3778,6 @@ read: st_read, write: st_write, ioctl: st_ioctl, - llseek: no_llseek, open: st_open, flush: st_flush, release: st_release, - Interesting Marcelo. How long has this been true in 2.6? In the 2.6 tree the tar --verify works with 2.6.7, but fails with 2.6.9. I am unable to test 2.6.8, but based on research of the code changes of 2.6.8 compared to the changes made in 2.4.27 re llseek I would expect 2.6.8 to fail as well with my DLT SCSI tape. Actually I just checked and it seems v2.6 is not using no_llseek. However John L. Males reports the same problem with v2.6 - John, care to retest with v2.6.10 ? My ability to test a 2.6.x kernel is limited to what 2.6.x kernel I can find on a livecd. The 2.6.7 and 2.6.9 kernel tests I conducted were using Knoppix 3.6 and 3.7. I do not have means at this time, nor time, to build up a dedicated drive to test 2.6.x kernels. If someone knows of or can build a 2.6.10 kernel on a live CD I will be happy to do the test. That said, I looked at the patch for 2.6.10 and seems alot of changes were made to st.c in 2.6.10. I did not see, but could of missed in looking, any lseek related change in 2.6.10. Given how it seems the test I ran with the change in st.c Marcell suggested what is the expected thought on this issue with 2.6.10? I am just asking from curiousity. Again, if someone can tell me of a live cd or can easly make a live cd with the 2.6.10 kernel I can test this issue wiht 2.6.10. Perhaps there is someone else with a DLT/SCSI tape driver that could test this tar --verify issue on 2.6.10? I thought I had an amanda problem, and eventually went to virtual tapes on disk, largely because of this. However, I have to say it is working better than tapes ever
Re: Problems with SCSI tape rewind / verify on 2.4.29
On Wed, 2 Mar 2005, Marcelo Tosatti wrote:
On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote:
Hi
Never had to log a bug before, hope this is correctly done.
Thanks
Mark
Detail
[1.] One line summary of the problem:
SCSI tape drive is refusing to rewind after backup to allow verify and
causing illegal seek error
[2.] Full description of the problem/report:
On backup the tape drive is reporting the following error and failing
it's backups.
tar: /dev/st0: Warning: Cannot seek: Illegal seek
I have traced this back to failing at an upgrade of the kernel to 2.4.29
on Feb 8th. The backups have not worked since. Replacement Drives have
been tried and cables to no avail. I noticed in the the changelog that a
patch by Solar Designer to the Scsi tape return code had been made.
BTW, this fix by Solar Designer introduces a bug to 2.4.29: a tape
driver is supposed to return ENOMEM in the case that was changed to return
EIO ;-(
v2.6 also contains the same problem BTW.
Try this:
--- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300
+++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300
@@ -3778,7 +3778,6 @@
read: st_read,
write: st_write,
ioctl: st_ioctl,
- llseek: no_llseek,
open: st_open,
flush: st_flush,
release:st_release,
This change covers up the problem. The real bug is in tar. The following
code is from tar is supposed to reposition the tape to the beginning of
the file jus written:
#ifdef MTIOCTOP
{
struct mtop operation;
int status;
operation.mt_op = MTBSF;
operation.mt_count = 1;
if (status = rmtioctl (archive, MTIOCTOP, (char *) operation), status
0)
{
if (errno != EIO
|| (status = rmtioctl (archive, MTIOCTOP, (char *)
operation),
status 0))
{
#endif
if (rmtlseek (archive, (off_t) 0, SEEK_SET) != 0)
{
/* Lseek failed. Try a different method. */
seek_warn (archive_name_array[0]);
return;
}
#ifdef MTIOCTOP
}
}
}
#endif
Here is output from strace showing what happens with 'tar -c -W' applied
at the beginning of the tape (this is using kernel 2.6.11-rc4 but the same
probably happens with 2.4.29):
...
ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE,
0x7fffecd0) = -1 EIO (Input/output error)
ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE,
0x7fffecd0) = -1 EIO (Input/output error)
lseek(3, 0, SEEK_SET) = -1 ESPIPE (Illegal seek)
So, both tape positioning commands fail and the code falls back to lseek.
Earlier it has returned success even though it has not done anything (this
was on purpose because it is the way some other Unices behave and with
reason). In that case this tar succeeded but it was pure luck. The first
BSF did position the tape correctly although it did fail.
The 2.6 st driver does contain this near the beginning of st_open():
nonseekable_open(inode, filp);
This probably makes lseek fail. This code has been in st.c since 2.6.8.
--
Kai
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI tape rewind / verify on 2.4.29
Kai Makisara [EMAIL PROTECTED] wrote: v2.6 also contains the same problem BTW. Try this: --- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300 +++ b/drivers/scsi/st.c2005-03-02 09:02:20.208159200 -0300 @@ -3778,7 +3778,6 @@ read: st_read, write: st_write, ioctl: st_ioctl, - llseek: no_llseek, open: st_open, flush: st_flush, release:st_release, This change covers up the problem. The real bug is in tar. In that case we're kinda screwed, and should change the kernel to make tar work again. We can send a bug report to the tar folks (good luck) and wait a few years. The first BSF did position the tape correctly although it did fail. (what's a BSF?) If it positioned the tape successfully, why did it claim that it failed? If we were to fix that up, would tar then be happy? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI tape rewind / verify on 2.4.29
Sorry gents, Let me correct this one more time. Regards, John L. Males Willowdale, Ontario Canada 02 March 2005 16:26 ** Reply Seperator ** On (Wed) 2005-03-02 16:15:07 -0500 John L. Males wrote in Message-ID: [EMAIL PROTECTED] To: [EMAIL PROTECTED] From: John L. Males [EMAIL PROTECTED] Subject: Re: Re[03]: Problems with SCSI tape rewind / verify on 2.4.29 Date: Wed, 2 Mar 2005 16:15:07 -0500 Marcelo, Sorry gents, seems the LKML used to handel the RE numbering in long past when I last mailed to LKML, bit not now, so resending this eMail to ensure goes back to orignal thread so all the eMail discussion is in one eMail thread. My applogies if this caused confusion on the LKML. Regards, John L. Males Willowdale, Ontario Canada 02 March 2005 (16:06 -) 16:15 ** Reply Seperator ** On (Wed) 2005-03-02 15:46:26 -0500 John L. Males wrote in Message-ID: [EMAIL PROTECTED] To: Marcelo Tosatti [EMAIL PROTECTED] From: John L. Males [EMAIL PROTECTED] Subject: Re[03]: Problems with SCSI tape rewind / verify on 2.4.29 Date: Wed, 2 Mar 2005 15:46:26 -0500 Hi Marcello, ** Reply Seperator ** On (Wed) 2005-03-02 11:34:41 -0300 Marcelo Tosatti wrote in Message-ID: [EMAIL PROTECTED] To: Gene Heskett [EMAIL PROTECTED] From: Marcelo Tosatti [EMAIL PROTECTED] Subject: Re: Problems with SCSI tape rewind / verify on 2.4.29 Date: Wed, 2 Mar 2005 11:34:41 -0300 n Wed, Mar 02, 2005 at 12:08:51PM -0500, Gene Heskett wrote: On Wednesday 02 March 2005 07:03, Marcelo Tosatti wrote: On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote: Hi Never had to log a bug before, hope this is correctly done. Thanks Mark Detail [1.] One line summary of the problem: SCSI tape drive is refusing to rewind after backup to allow verify and causing illegal seek error In my experiences with this problem that I am sure is exactly the same issue, the tape in fact does rewind after creating the tar to then perfore the --verify option. The illegal see error seems to arise after the rewind or more correctly bsf commands may be being used (but not confirmed this yet, another test I need to do in few days). For sure the tape is positionted back. I know as I have also done this test with larger directories and know and have heard the tape take long time to naturally get back to the start of tar file to be able to perform the --verify option. That said I am using a DLT drive. Perhpas with different drivers or tape drivers this issue may have variations on theme and behaviour with net result the same error message and/or root cause. [2.] Full description of the problem/report: On backup the tape drive is reporting the following error and failing it's backups. tar: /dev/st0: Warning: Cannot seek: Illegal seek I have traced this back to failing at an upgrade of the kernel to 2.4.29 on Feb 8th. The backups have not worked since. Replacement Drives have been tried and cables to no avail. I noticed in the the changelog that a patch by Solar Designer to the Scsi tape return code had been made. Last kernel to work correctly in 2.4 branch was 2.4.26. Kernel versions 2.4.27, 2.4.28 and 2.4.29 all fail based on my experience with DLT SCSI based tape. v2.6 also contains the same problem BTW. Try this: --- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300+++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300@@ -3778,7 +3778,6 @@ read: st_read, write: st_write, ioctl: st_ioctl, - llseek: no_llseek, open: st_open, flush: st_flush, release: st_release, - Interesting Marcelo. How long has this been true in 2.6? In the 2.6 tree the tar --verify works with 2.6.7, but fails with 2.6.9. I am unable to test 2.6.8, but based on research of the code changes of 2.6.8 compared to the changes made in 2.4.27 re llseek I would expect 2.6.8 to fail as well with my DLT SCSI tape. Actually I just checked and it seems v2.6 is not using no_llseek. However John L. Males reports the same problem with v2.6 - John, care to retest with v2.6.10 ? My ability to test a 2.6.x kernel is limited to what 2.6.x kernel I can find on a livecd. The 2.6.7 and 2.6.9 kernel tests I conducted were using Knoppix 3.6 and 3.7. I do not have means at this time, nor time, to build up a dedicated drive to test 2.6.x kernels. If someone knows of or can build a 2.6.10 kernel on a live CD I will be happy to do the test. That said, I looked at the patch for 2.6.10 and seems alot of changes were made to st.c in 2.6.10. I did not see, but could of missed in looking, any lseek related change in 2.6.10. Given how it seems the test I ran
Re: Problems with SCSI tape rewind / verify on 2.4.29
On Wed, Mar 02, 2005 at 11:17:19PM +0200, Kai Makisara wrote:
On Wed, 2 Mar 2005, Marcelo Tosatti wrote:
On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote:
Hi
Never had to log a bug before, hope this is correctly done.
Thanks
Mark
Detail
[1.] One line summary of the problem:
SCSI tape drive is refusing to rewind after backup to allow verify and
causing illegal seek error
[2.] Full description of the problem/report:
On backup the tape drive is reporting the following error and failing
it's backups.
tar: /dev/st0: Warning: Cannot seek: Illegal seek
I have traced this back to failing at an upgrade of the kernel to 2.4.29
on Feb 8th. The backups have not worked since. Replacement Drives have
been tried and cables to no avail. I noticed in the the changelog that a
patch by Solar Designer to the Scsi tape return code had been made.
BTW, this fix by Solar Designer introduces a bug to 2.4.29: a tape
driver is supposed to return ENOMEM in the case that was changed to return
EIO ;-(
Reverted.
v2.6 also contains the same problem BTW.
Try this:
--- a/drivers/scsi/st.c.orig2005-03-02 09:02:13.637158144 -0300
+++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300
@@ -3778,7 +3778,6 @@
read: st_read,
write: st_write,
ioctl: st_ioctl,
- llseek: no_llseek,
open: st_open,
flush: st_flush,
release:st_release,
This change covers up the problem. The real bug is in tar. The following
code is from tar is supposed to reposition the tape to the beginning of
the file jus written:
#ifdef MTIOCTOP
{
struct mtop operation;
int status;
operation.mt_op = MTBSF;
operation.mt_count = 1;
if (status = rmtioctl (archive, MTIOCTOP, (char *) operation), status
0)
{
if (errno != EIO
|| (status = rmtioctl (archive, MTIOCTOP, (char *)
operation),
status 0))
{
#endif
if (rmtlseek (archive, (off_t) 0, SEEK_SET) != 0)
{
/* Lseek failed. Try a different method. */
seek_warn (archive_name_array[0]);
return;
}
#ifdef MTIOCTOP
}
}
}
#endif
Here is output from strace showing what happens with 'tar -c -W' applied
at the beginning of the tape (this is using kernel 2.6.11-rc4 but the same
probably happens with 2.4.29):
...
ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE,
0x7fffecd0) = -1 EIO (Input/output error)
ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE,
0x7fffecd0) = -1 EIO (Input/output error)
lseek(3, 0, SEEK_SET) = -1 ESPIPE (Illegal seek)
So, both tape positioning commands fail and the code falls back to lseek.
Earlier it has returned success even though it has not done anything (this
was on purpose because it is the way some other Unices behave and with
reason). In that case this tar succeeded but it was pure luck. The first
BSF did position the tape correctly although it did fail.
The 2.6 st driver does contain this near the beginning of st_open():
nonseekable_open(inode, filp);
This probably makes lseek fail. This code has been in st.c since 2.6.8.
Thanks for the cluebat Kai, is this problem fixed in newer versions of tar?
I suspect v2.4 should work with older versions of tar, so we should keep
lseek working to make it happy. What is your opinion?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI tape rewind / verify on 2.4.29
Andrew Morton wrote: (what's a BSF?) Backward space count files (man mt). -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI tape rewind / verify on 2.4.29
On Wed, 2 Mar 2005, Marcelo Tosatti wrote: On Wed, Mar 02, 2005 at 11:17:19PM +0200, Kai Makisara wrote: ... BTW, this fix by Solar Designer introduces a bug to 2.4.29: a tape driver is supposed to return ENOMEM in the case that was changed to return EIO ;-( Reverted. Thanks. ... Thanks for the cluebat Kai, is this problem fixed in newer versions of tar? The current CVS version seems to have the same code I quoted. I suspect v2.4 should work with older versions of tar, so we should keep lseek working to make it happy. What is your opinion? I commented this in the other reply I just sent and I don't have a clear preference. I just hope that 2.4 and 2.6 are fixed in a compatible way. -- Kai - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI tape rewind / verify on 2.4.29
Kai Makisara [EMAIL PROTECTED] wrote: f seek with tape is changed back to returning success, this would enable correct tar --verify at the beginning of the tape. However, I am not sure what happens if we are not at the beginning. I will investigate this and suggest a long term fix to the tar people (a fix that should be compatible with all Unix tape semantics I know) and also suggest possible fixes to st (this may include automatic writing of a filemark when BSF is used after writes). Yes, please let's get a tar fix in the pipeline. GNU tar must run on a lot of operating systems. It's odd. If you think want to make st return success for seeks even if nothing happens (as it did earlier), I don't have anything against that. It would solve the practical problem several people have reported recently. (My recommendation for the people seeing this problem is to do verification separately with 'tar -d'.) Yes, I think we need to grit our teeth and do this. I'll stick a comment in there. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with SCSI tape rewind / verify on 2.4.29
Marcelo,
My couple cents worth:
On Wed, Mar 02, 2005 at 11:17:19PM +0200, Kai Makisara wrote:
On Wed, 2 Mar 2005, Marcelo Tosatti wrote:
On Wed, Mar 02, 2005 at 11:15:42AM -, Mark Yeatman wrote:
Hi
Never had to log a bug before, hope this is correctly done.
Thanks
Mark
Detail
[1.] One line summary of the problem:
SCSI tape drive is refusing to rewind after backup to allow
verify and causing illegal seek error
[2.] Full description of the problem/report:
On backup the tape drive is reporting the following error and
failing it's backups.
tar: /dev/st0: Warning: Cannot seek: Illegal seek
I have traced this back to failing at an upgrade of the kernel
to 2.4.29 on Feb 8th. The backups have not worked since.
Replacement Drives have been tried and cables to no avail. I
noticed in the the changelog that a patch by Solar Designer to
the Scsi tape return code had been made.
BTW, this fix by Solar Designer introduces a bug to 2.4.29: a
tape driver is supposed to return ENOMEM in the case that was
changed to return EIO ;-(
Reverted.
v2.6 also contains the same problem BTW.
Try this:
--- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300
+++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300
@@ -3778,7 +3778,6 @@
read: st_read,
write: st_write,
ioctl: st_ioctl,
- llseek: no_llseek,
open: st_open,
flush: st_flush,
release:st_release,
This change covers up the problem. The real bug is in tar. The
following code is from tar is supposed to reposition the tape to
the beginning of the file jus written:
#ifdef MTIOCTOP
{
struct mtop operation;
int status;
operation.mt_op = MTBSF;
operation.mt_count = 1;
if (status = rmtioctl (archive, MTIOCTOP, (char *)
operation), status
0)
{
if (errno != EIO
|| (status = rmtioctl (archive, MTIOCTOP, (char *)
operation),
status 0))
{
#endif
if (rmtlseek (archive, (off_t) 0, SEEK_SET) != 0)
{
/* Lseek failed. Try a different method. */
seek_warn (archive_name_array[0]);
return;
}
#ifdef MTIOCTOP
}
}
}
#endif
Here is output from strace showing what happens with 'tar -c -W'
applied at the beginning of the tape (this is using kernel
2.6.11-rc4 but the same probably happens with 2.4.29):
...
ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE,
0x7fffecd0) = -1 EIO (Input/output error)
ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE,
0x7fffecd0) = -1 EIO (Input/output error)
lseek(3, 0, SEEK_SET) = -1 ESPIPE (Illegal seek)
So, both tape positioning commands fail and the code falls back to
lseek. Earlier it has returned success even though it has not done
anything (this was on purpose because it is the way some other
Unices behave and with reason). In that case this tar succeeded
but it was pure luck. The first BSF did position the tape
correctly although it did fail.
The 2.6 st driver does contain this near the beginning of
st_open():
nonseekable_open(inode, filp);
This probably makes lseek fail. This code has been in st.c since
2.6.8.
Thanks for the cluebat Kai, is this problem fixed in newer versions
of tar?
My testing last week or so has been with the latest tar, tar-1.15.1-2,
tar 1.14 and 1.13 had same lseek --verify issues.
I suspect v2.4 should work with older versions of tar, so we should
keep lseek working to make it happy. What is your opinion?
I would agree in the lseek sense. I feel that if there is some bad
behaviour in tar it should be reported to the tar folks to be fixed so
long term things are done correctly and over time the kernel
worarounds can be depreciated.
Regards
John L. Males
Willowdale, Ontario
Canada
02 March 2005 (17:04 -) 17:25
==
Bmer ... Boom Boom, how are you Boom Boom
Meow, meoaa as Boomer loudly announces
intent Boomer is coming for attention
Loved to kneed arm and lick arm with Boomers very large
tongue
Able to catch, or at least hit, almost any object in flight
withing reach of front paws
Boomer 1985 (Born), Adopted 04 September 1991
04 September 1991 - 08 February 2000 18:50
How are you Mr. Sylvester?
... Grunt Grunt ... quick licks of nose
Rolls over for pet and stomac rub when Dad arrives home
and grunting
Runs back and forth from study, tilts head as glowing green
eyes stare for attention please, grunts and meows,
repeats run, tilt head and stare few times for good
Re: Problems with SCSI tape rewind / verify on 2.4.29
Andrew/Kai, List: linux-kernel Subject:Re: Problems with SCSI tape rewind / verify on 2.4.29 From: Andrew Morton akpm () osdl ! org Date: 2005-03-02 22:17:11 Message-ID: 20050302141711.00ec7147.akpm () osdl ! org [Download message RAW] Kai Makisara [EMAIL PROTECTED] wrote: f seek with tape is changed back to returning success, this would enable correct tar --verify at the beginning of the tape. However, I am not sure what happens if we are not at the beginning. I will investigate this and suggest a long term fix to the tar people (a fix that should be compatible with all Unix tape semantics I know) and also suggest possible fixes to st (this may include automatic writing of a filemark when BSF is used after writes). Kai, I have a second problem that is perhaps another case of kernel and tar combined effect problem. I have not had time to test with the 2.6.7 and 2.6.9 knoppix based kernels to see if same problem as = 2.4.26 has. Can you hold out about 3-4 days for me to do the test and report the issue to Marcelo to screen first, Kai? I have feeling what I experienced in testing change to st.c Marcelo suggested that caused me to try 2.4.26 again and fail on this new issue has some bearing on tape positioning you want to check out. Yes, please let's get a tar fix in the pipeline. GNU tar must run on a lot of operating systems. It's odd. If you think want to make st return success for seeks even if nothing happens (as it did earlier), I don't have anything against that. It would I think it is important if an error is enccountered a non-successful return (code) is returned. If an action is required that requires no action as it is at the place/state/position being requested it is reasonable to return a successful return (code). solve the practical problem several people have reported recently. (My recommendation for the people seeing this problem is to do verification separately with 'tar -d'.) As aside, I have tried the tar -d option as well and it worked, but was my understanding the --verify does a data readback compare of the files in the tar, whereas the tar -d option only compares if files names in tar to directory? That to me means a big difference in confidance the tar backup is ok, as I look to have readback verify to increase confidance of backup success. Yes, I think we need to grit our teeth and do this. I'll stick a comment in there. Regards, John L. Males Willowdale, Ontario Canada 02 March 2005 (17:45 -) 18:51 == Bmer ... Boom Boom, how are you Boom Boom Meow, meoaa as Boomer loudly announces intent Boomer is coming for attention Loved to kneed arm and lick arm with Boomers very large tongue Able to catch, or at least hit, almost any object in flight withing reach of front paws Boomer 1985 (Born), Adopted 04 September 1991 04 September 1991 - 08 February 2000 18:50 How are you Mr. Sylvester? ... Grunt Grunt ... quick licks of nose Rolls over for pet and stomac rub when Dad arrives home and grunting Runs back and forth from study, tilts head as glowing green eyes stare for attention please, grunts and meows, repeats run, tilt head and stare few times for good measure, grunts and meows Lays on floor just outside study to guard Dad Loved to groom Miss Mahogany, and let Mahogany cuddle beside Sylvester 1989 (estimated Born) Found in building mail area noon hour 09 Feburary 1992 09 February 1992 - 19 January 2003 23:25 Hello Miss Chicago 'White Sox', how are you 'Chico'? Grunt (thank you) ... as put out food for Chicago ME So loud the world stops A very determined Miss White Sox AKA Chico ... Cheryl Crawford used as nickname Loved to chase kibble slid down hall floor, bat about and then eat Loved to hook paw in dish to toss out a single kibble at time, dart at as moved, then eat ... Crunches Chicago White Sox, Chico August 1989 (born), adopted 04 February 1991 05 October 2004 06:52 Quite Grunts as lay Chicago on bed for last time 04 February 1991 - 05 October 2004 07:32 pgp7yXKaQLjXX.pgp Description: PGP signature
Re: Problems with SCSI tape rewind / verify on 2.4.29
On Wed, 2 Mar 2005, Andrew Morton wrote: Kai Makisara [EMAIL PROTECTED] wrote: v2.6 also contains the same problem BTW. Try this: --- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300 +++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300 @@ -3778,7 +3778,6 @@ read: st_read, write: st_write, ioctl: st_ioctl, -llseek: no_llseek, open: st_open, flush: st_flush, release:st_release, This change covers up the problem. The real bug is in tar. In that case we're kinda screwed, and should change the kernel to make tar work again. We can send a bug report to the tar folks (good luck) and wait a few years. The first BSF did position the tape correctly although it did fail. (what's a BSF?) If it positioned the tape successfully, why did it claim that it failed? BSF moves the tape backwards over filemarks. tar tries to move over one filemark. It does not find it because it ends to the beginning of the tape. This is why the operation fails. However, the tape is at the beginning and this is the correct place with regard to what is done next. If we were to fix that up, would tar then be happy? It is not fixable in the kernel. The beginning of the tape is a special case because there is no filemark. Any application should take this into account. We could fake a filemark there but this would lead to problems because then we could skip backwards indefinitely even when the tape moves nowhere. This could confuse other applications. If seek with tape is changed back to returning success, this would enable correct tar --verify at the beginning of the tape. However, I am not sure what happens if we are not at the beginning. I will investigate this and suggest a long term fix to the tar people (a fix that should be compatible with all Unix tape semantics I know) and also suggest possible fixes to st (this may include automatic writing of a filemark when BSF is used after writes). If you think want to make st return success for seeks even if nothing happens (as it did earlier), I don't have anything against that. It would solve the practical problem several people have reported recently. (My recommendation for the people seeing this problem is to do verification separately with 'tar -d'.) -- Kai - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
