Mail Archives: cygwin/2004/08/19/11:48:07
On Aug 19 16:47, Pim Zandbergen wrote:
> Anyway, I think I've found the problem. When the system boots, mt status
> shows a tape block size of 0. ntbackup seems to change it to 16k. That makes
> dd hang in the next script. using "mt setblk 0" before dd, and adding
> "bs=16k"
> to the dd command line solves the problem.
That's weird somehow. I only have experience myself with DDS-2, DDS-3
and SLR drives but all of them were set to 512 bytes blocksize after a
reboot. Note that the blocksize is initially set by the OS, not by
Cygwin. As long as you (or some application) didn't set the blocksize,
it has the OS setting. FWIW, I never saw are heard of a tape device
driver which is set to variable blocksize (0) by default. What drive are
you using? Could you mail the output of `mt status 3' after a reboot?
> Somehow, the old code would not hang in this situation, the new code does.
>
> My problem seems solved now, but this should allow you to reproduce the
> problem immediately:
>
> mt -f /dev/st0 setblk 16384
> dd if=/dev/zero of=/dev/st0 bs=16k count=1
Works like a charm for me. I tried with blocksize set to 0 and to 16384.
Neither mt, nor dd hang, *except* one application is still accessing the
tape device. In that case, the blocking open call hangs until the first
application has closed the file descriptor. The device access is exclusive
since 1.5.10. However, I've checked in a change which will return an EBUSY
error to the second process instead of hanging in the open(2) call.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:cygwin AT cygwin DOT com
Red Hat, Inc.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -