lkml.org 
[lkml]   [2005]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Problems with SCSI tape rewind / verify on 2.4.29
On Wed, 2 Mar 2005, Andrew Morton wrote:

> Kai Makisara <Kai.Makisara@kolumbus.fi> 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:10    [W:0.083 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site