Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Thu, 19 Aug 2004 17:48:22 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: 1.5.10-3 + mt 2.3 scsi tape problems
Message-ID: <20040819154822.GB10590@cygbert.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4122275D DOT 6010101 AT macroscoop DOT nl> <20040817155426 DOT GN1689 AT cygbert DOT vinschen DOT de> <4124BD84 DOT 4020304 AT macroscoop DOT nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4124BD84.4020304@macroscoop.nl>
User-Agent: Mutt/1.4.2i

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/