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 -0000, 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,
> 0x7fffffffecd0) = -1 EIO (Input/output error)
> ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE,
> 0x7fffffffecd0) = -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/
