DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=c1FbU4vGaMJSKvti+bBg/SfpQFw1ekJU66nD3fw90bEUVlf0pQlLs
	GTp5XfRhMLDRXdKGlaBISteqPb4ih5yU9tM1taLMZ9Vxt3d54yRMrWff+If7ufBS
	4SwjPlExr39nQ5g9H+s+bqOJCInu2p1rPUQVGHpnouSREDi3HSZmww=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Mon, 19 Aug 2013 12:19:17 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: mt and tar fail on LTO-5 drives
Message-ID: <20130819101917.GC18757@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <520FC274 DOT 3040001 AT mailme DOT ath DOT cx>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="f+W+jCU1fRNres8c"
Content-Disposition: inline
In-Reply-To: <520FC274.3040001@mailme.ath.cx>
User-Agent: Mutt/1.5.21 (2010-09-15)

--f+W+jCU1fRNres8c
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Aug 17 20:35, bartels wrote:
> Hello People,
>=20
> I have here two SAS connected LTO-5 drives: one IBM and one HP.
>=20
> Both drives work work fine, but sadly mt does not.
> The size reported by mt is a meager 35 GB, instead of the expected 1.5TB
>=20
> I have tried both an older 32 bit and the 'current' 64 bit cygwin: same r=
esult.
>=20
> Writing to tape works fine with tar, but the tape is quickly considered '=
full'.
> Is there any hope of fixing this? LTO-6 is already out there.

I don't know.  Cygwin uses the Win32 tape API.  The OS function
GetTapeParameters returns the capacity and the # of remaining bytes as 8
bytes LARGE_INTEGER value.  The size of LT)-5 or LTO-6 should fit easily
into that.

I just checked that the value is stored within Cygwin as 8 byte long
long value, so no problem there.  The mt tool prints the value as %lld
value, so it should print it correctly as 8 byte value.  From what I can
see, the wrong value *seems* to be returned by the OS.

Also, the write(2) function does not check for the remaining bytes, so I
wonder why tar should fail prematurely, unless there's a problem with
the block number.  The OS function GetTapePosition returns the current
block number as LARGE_INTEGER, but Cywin stores it in a 32 bit int.  So
the block number overflows after 4 billion blocks.  But even with a
small blocksize of 512 bytes this would only occur at about 2 TB of
data, long after the end of the tape.  Despite that this is more of a
theoretical problem, the mtop struct to pass parameters to ioctl(fd,
MTIOCTOP, ...) only allows 4 byte count values anyway, even on Linux.

Another potential problem is if you try to use blocksizes > 64K.  I don't
know if that's still a problem in newer Windows versions, but with older
versions including Windows XP, the OS didn't handle blocksizes > 64K
correctly and we got spurious error messages.  Something about this
should be in the mailing list archives of old.

But the bottom line is, I have no way to test and debug that, since I
don't have access to an LTO-5 drive, nor do I have a Windows machine
with SAS controller.  However, since Cygwin as well as the mt tool are
Open Source, maybe you can have a look and debug this issue?


Thanks,
Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--f+W+jCU1fRNres8c
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJSEfElAAoJEPU2Bp2uRE+g+bcP/jyKT3B883AA5t67+SDSh9Q1
GpOTNeXj+0vUjLa7D55Wu+U2ZnoUDNRn2X5CIt35vdPVKfY9Rbev/IgKsWIKzBgV
p+38DwzmBcNTGNw6cJ99vJkqluA42dYSzh1y17rdSOzPG+KtCGaBJsQGkFHWwEX4
MvKT/W1qnE5grSqAkimwqpuKEesxbe5TQzsYf8Ir8y9siRz9SIw1ikLkQpJM7Z6W
91JCifoCS2tP3maIaymKlG7/f4k6eVifwFfnS0D/3Wm9GY3m/maj9k/aDE9BmfzZ
lPX9Jke3rah6wDRIG+R5PV3BZpN+DsbmPv0h37ut7maKgIA7/hY+o42K+iIX6Co4
YY/0eCou32A799dJcu6M3m6LFcresVRmcumLrQQ5MLkDkfP4xaJxuPmPjSrm1Gtq
3p7sqg3IF2mTSCNkfBz6NEYPMqocsCzV1sGmST5/quWKKGqRn+fhdAkPYgsO1bZG
tMsUQ7le2B4HtMZHEGqcbzpDeNNm4rEsTc22UVCTFz2Onc+6DAb1Qk0xNJ1GQ5cz
YccJPqDdIiW8fJUN2yuTheOdpPbQtMHYpe8NVSZ3ro6OBuNQM96gGxHNcHG/2cdo
LmGq8z1/K+TyM0RnSRmzF3+JGgRNVb2M2PB0kR3ALGX493adQwilWg9AvKdG1bjr
YOFIjb/y5ZTjbBvEIB1N
=gjSP
-----END PGP SIGNATURE-----

--f+W+jCU1fRNres8c--