On Tue, 5 Feb 2008, Kai Makisara wrote: > On Mon, 4 Feb 2008, James Bottomley wrote: > > > > > On Mon, 2008-02-04 at 22:28 +0100, Borislav Petkov wrote: > > > On Mon, Feb 04, 2008 at 03:22:06PM +0100, maximilian attems wrote: > > > > > > (Added Bart to CC) > > > > > > > hello borislav, > > > > ... > > > > This does still occur with 2.6.22; with a blank tape in my HP DDS-4 drive: > > > > > > > > $ tar tzvf /dev/nst0 > > > > tar: /dev/nst0: Cannot read: Input/output error > > > > That's a SCSI tape, not an IDE one. I cc'd the SCSI list > > > This is not a bug, it is a feature. There is _nothing_ on the tape and if > you try to read something, you get an error. The same thing applies to > reading after the last filemark. Note that after writing a filemark at the > beginning of the tape, the situation is different. Now there is a file and > the normal EOF semantics apply although there still is no data. > > I admit that the error return could be more descriptive but the st driver > tries to be compatible with other Unices. > > The behavior can be changed if Linux does not match other Unices. I don't > remember if I have tested just this with other Unices. I will try to test > this with Tru64 tomorrow. If anyone has data on other Unices, it would be > helpful. > None of our Tru64 boxes have a user-accessible tape drive any more. However, I have been able to test with a Solaris box. The behavior there matches the Linux behavior: blank tape -> i/o error when trying to read. -- Kai - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
