Re: dd hangs when attempting to access a tape drive

[Curt Blank]

I'll do that first thing tomorrow, my backup is about to kick off at 
02:00. I had hoped I provided a good amount of information to get 
started, and thanks. I found a way to label tapes without dd. My first 
attempt with perl could read existing labels but could not write them. I 
then moved to C and discovered what I think might have something to do 
with the problem.

At first I could not write the tapes with C either, the fclose kept 
failing and the data definitely was not on the tape. Then I got to 
thinking about blocking factor, so I padded the write to 512 bytes, the 
block size reported in the boot log for the tape drives, and wahla, it 
worked. So then I went back to perl and tried the same thing, bingo, 
worked there to.

So then I went to dd, I know you're hoping, but nada, still hung, I left 
it for 3300+ seconds according to dd's report and the only way I could 
get the command prompt back was to either force the drive to unload at 
the front panel or power down the library. I forgot which, I was trying 
so many things and I didn't take notes. The tape drive showed Active the 
whole 3300+ seconds. I was starting to wondering if it was spinning out 
to EOT but there's no way I can see that while it's occurring.

So I think it might have something to do with block size. I set bs to 
512 but the data in the file "if" used was only 31 bytes. I'll probably 
try by padding the "if" file to 512 and see what happens.

But and here's the catch, this used to work under SuSE 8.1 with a 2.4 
kernel, reading and writing with a bs of 32. It's only as of Wednesday 
and SuSE 9.3 with the 2.6 kernel that the problem started, so something 
changed somewhere. Don't get me wrong, I'm not complaining, just trying 
to figure it out.

Thanks,

-Curt Blank

Jim Meyering wrote:
> Thanks for the detailed report.
> To narrow it down a little more, please run dd via strace, e.g.,
>
>   strace -o log dd if=file.name of=/dev/nst0 bs=32 count=1
>
> Then, at least, we'll have a good idea which syscall is causing
> the trouble.
>
> On general principle, a process that cannot be killed
> via `kill -9' suggests a kernel bug.  But even if that's
> the case, we may want to make dd avoid triggering it.
>
> Curtis J Blank <address@hidden> wrote:
>
> > I've got a problem were dd hangs attempting to access a tape drive, this
> > used to work fine. The only change is going to the 2.6 kernel, SuSE's 9.3
> > 2.6.11.4-21.9 to be exact. The dd command is (this is all done as root):
> >
> > dd if=file.name of=/dev/nst0 bs=32 count=1
> > or
> > dd if=/dev/nst0 bs=32 count=1
> >
> > If it's done command line you cannot ^C out of it, and command line or in
> > a cron job you cannot kill -9 the process, the only way to get rid of it
> > is to reboot. mt can access the drive just fine, tar can read and write
> > the drive just fine.
>
> ...