Re: Problems with SCSI tape rewind / verify on 2.4.29

[Kai Makisara]

On Wed, 2 Mar 2005, Andrew Morton wrote:

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