On Sun, Jun 17, 2007 at 09:52:10PM -0700, Tim Kientzle wrote:
> Colin Percival wrote:
> > Tim Kientzle wrote:
> >> I fear I'll have to avoid seeks ... tape drives on
> >> FreeBSD seem to return garbage from lseek().
> > Is there any reason why the tape drivers can't be fixed?
>
> Since people are running into this problem today
> on 6.2, I'm planning to fix it where I can. :-/
>
> The basic problem is that an lseek() call to a tape
> drive returns success exactly as if it worked.
> Daniel O'Connor recently sent me the following
> ktrace from bsdtar doing a tar -t of an uncompressed
> tar archive from his Tandberg TS400 connected to an
> Adaptec 29160 controller:
>
> 5378 bsdtar CALL lseek(0x3,0,0,0x1)
> 5378 bsdtar RET lseek 51200/0xc800
> 5378 bsdtar CALL lseek(0x3,0,0x2f800,0x1)
> 5378 bsdtar RET lseek 245760/0x3c000
>
> Note that the second call returns a new file position
> that's exactly 0x2f800 bytes beyond the former file
> position, even though nothing has actually happened.
>
> I think any of the following would be reasonable behaviors:
> * lseek() could return ESPIPE ("illegal seek")
> * lseek() could return an unchanged file offset
> (indicating that the file position was unchanged by
> the attempted seek).
> * lseek() could return ENOTSUP ("unsupported operation")
> As I said though, I just don't know that code well
> enough to propose a fix.
Then it should be fixed in the driver, please do not mask this bug in the
bsdtar workaround. Ask adaptec driver people for help.
--
http://ache.pp.ru/
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
