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/
