Description of Problem: Trying to append files using "tar -rvf /dev/st0 some_dir_with_files" into a Seagate TR5 ide tape errors out with the following message: tar: /dev/st0: wrote only 0 of 10240 bytes tar: Error is not recoverable: exiting now Version-Release number of selected component (if applicable): Both ide-scsi and ide-tape drivers produce the same error. How Reproducible: always Steps to Reproduce: 1. rmmod ide-tape; modprobe ide-scsi; hdparm -d /dev/hdb; mt -f /dev/st0 stoptions no-blklimits 2. tar -cvf /dev/st0 /usr/src/linux/drivers/scsi tar -xvf /dev/st0 3. tar -rvf /dev/st0 /usr/src/linux/drivers/net Actual Results: Can't append files to an archive on the tape. It errors out with the following message: tar: /dev/st0: wrote only 0 of 10240 bytes tar: Error is not recoverable: exiting now Expected Results: To be able to append files into an archive in the tape Additional Information:
Created attachment 32838 [details] /var/log/messages
This happens with 2.4.7-10smp (RH7.2). I will try with the RCs.
RC1 shows the same problem. "tar -rf /dev/ht0 file_to_add_to_archive_on_tape" doesn't work. But it is possibe to dump multiple archives on the tape and use "mt" command to move around.
Created attachment 32958 [details] trace of the commands I used to create multiple archives
On the above attached file, /dev/tape was linked to /dev/nht0.
hdparm -d does not do anything, please use hdparm -d0 /dev/hdb as a first step. Status: I fixed an obvious problem with switch fall-through in idetape_mtioctop(), but now the TR-5 barfs with check and ASC 0x80 ASCQ 0x81. I'll look into it and perhaps take it up with Seagate.
Why do we have this ENORMOUS cc list of Dell people on this bug? Those who do not want being spammed are welcome to drop themselves.
Created attachment 33804 [details] Checkpoint after 2.5 fixes
What makes people think that tar -r is possible to implement on Seagate TR-5? So far I have seen only evidence to the contrary. An attempt to space by one block back causes the tape to "space" by one 512 byte block, not by a tar block.
****Joshua Giles comment on March 28, 2002**** Problem still evident in Hampton beta3
What do you expect, hardware cannot do it. Of course, by some Murphy's law, I had to fix driver bugs first to find that out. Why do you expect this to work? Does it work on any other OS?
There aren't any issues seen with other OSes. The device doesn't support UDMA, so it would be good if DMA is disabled on this device by default.
This bug has nothing to do with DMA, so my question stands. Michael, you obviously confused this bug with bug 54517.
I'm not sure why this bug has stayed open so long. Appending to tapes is not supported (except, in some cases, on an "if it breaks you get to keep both pieces" basis). Most tar man pages I have read on other systems said things like "appending only works for files, not tapes". I'd like to understand why this shouldn't be closed NOTABUG.
Modern streaming tapes do not support tar -r, period. Closing NOTABUG.