Mail Archives: cygwin/2013/08/19/13:12:22
--96YOpH+ONegL0A3E
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Aug 19 18:21, bartels wrote:
> On 08/19/2013 12:19 PM, Corinna Vinschen wrote:
> >On Aug 17 20:35, bartels wrote:
> >>Hello People,
> >>
> >>I have here two SAS connected LTO-5 drives: one IBM and one HP.
> >>
> >>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
> >>
> >>I have tried both an older 32 bit and the 'current' 64 bit cygwin: same=
result.
> >>
> >>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.
> >[...]
> >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?
>=20
> Thanks for your time.
>=20
> I did have a look.
> The size reported to mt by the os seems to be the root cause: it is 38_24=
7_858_176 bytes, instead of 1.5TB
Really? Can you safely confirm that this is the value returned by the
GetTapeParameters call in mtinfo_drive::get_mp()? If it's returned by
mt, it's not a safe bet since the data could be screwed up due some
as yet unknown Cygwin or mt bug.
To be really sure, you could add debug output to Cygwin's
mtinfo_drive::get_mp function and rebuild the DLL:
diff -u -p -r1.90 fhandler_tape.cc
--- fhandler_tape.cc 19 Aug 2013 10:24:37 -0000 1.90
+++ fhandler_tape.cc 19 Aug 2013 16:40:23 -0000
@@ -101,6 +101,8 @@ mtinfo_drive::get_mp (HANDLE mt)
{
DWORD len =3D sizeof _mp;
TAPE_FUNC (GetTapeParameters (mt, GET_TAPE_MEDIA_INFORMATION, &len, &_mp=
));
+ if (!lasterr)
+ system_printf ("Capacity %D Remaining %D", _mp.Capacity, _mp.Remaining=
);
return error ("get_mp");
}
=20
This prints the raw values returned by the OS to your terminal.
> My tar blocksize for the earlier test was 64 KB, within spec.
> HP has a max blocksize 512 KB, which seems to work fine.
> Still, it stops on an error after 36 GB (just as it does with -b 2048):
>=20
> + tar -f /dev/nst0 -c -b 524288 blah
> tar: /dev/nst0: Cannot write: No space left on device
> tar: Error is not recoverable: exiting now
>=20
> mt reports matching capacity, remaining and block:
>=20
> $ mt -f /dev/nst0 status 2
> drive type : 56 (STK 9840)
> tape capacity : 38247858176 B
> tape capacity : 37351424 KB remaining : 2105344 KB
> current file : -1 active partition : 0
> current block : -1 cur logical block: 73373
> General status bits on (10b0000):
> ONLINE IM_REP_EN HW_ECC HW_COMP
> min block size : 2 max block size : 524288
> def block size : 131072 cur block size : 0
> density code : 58 (Ultrium LTO-5)
>=20
> The IBM drive shows similar numbers and behaviour, slightly
> different error msg ('Cannot close' instead of 'Cannot write'):
> + tar -f /dev/nst1 -c -b 2048 blah
> tar: /dev/nst1: Cannot close: No space left on device
> tar: Exiting with failure status due to previous errors
It would be interesting to see the OS error codes. If you run tar under
strace, the trace output should contain a line like
[...] write: Win32 error XXXX
or
[...] close: Win32 error XXXX
The value of XXXX is what I'm curious about.
> I suppose there is nothing for cygwin to do, other
> than adding some items to the 'density' list:
> {0x44, "Ultrium LTO-3"},
mt already knows LTO-3 and 4.
> {0x58, "Ultrium LTO-5"},
Thanks, I add that to CVS.
> How do I best report this to Microsoft?
Assuming this is really a OS bug and not some error in Cygwin we just
didn't figure out yet, reporting to Microsoft requires to open a support
case. A testcase with plain OS tape API functions and without any
Cygwin functions in between would be required, otherwise it will be
immediately blamed on Cygwin. And some endurance is required to get
over the first support line.
> Any chance they fix it, you reckon?
I would be overly optimistic to say yes here... a careful "maybe"
is ok, though.
Corinna
--=20
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--96YOpH+ONegL0A3E
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAEBAgAGBQJSElHjAAoJEPU2Bp2uRE+g4JwP/2NsPXrHTjneXjje0sHLSMJg
TNgkfg80CtPNrz0p6aDl5Ak5Yyi2Y089sha9A+c7hQjL/ankDTXGUTCEZTTbMHzA
gprRVDZYgSyNbbR83BO/2Q8PungF9zQupDIqgyMcFr46M12zsiZa8WOoZYQCJPnL
m4jtmdxwcMr2NOn9Kgn8BX6vg58wYwJkefkSB4dRl4xKqW+/FAjvttzj6fcUYZrA
Sjbhpu7Wf0JJDf7wAjJVuZY/QdlpcsuccHbPXMwRSjPFRhRTU4UdV+FbcYoiT6Bh
kox/pAYqYqQE4HssczV5WE92GYx2aozP1lQfeLAl5VOTghLEYytUYhfZ4c2fNo9e
xtbAdjmhZVMNzSVLFznicSPd/F2xhrtqBjMxiyIpAPNSNl5LCJscsEUEECg+DxbH
+ku0BcM9NH3u1Z/mMzr2m3DqJ0S+tkITCVQUto/7WMTehbju41L7X/8kotFA57fr
Yqh4UkNriqFS9VI61SpKVdfIC1lysxl7Gsa71eEb3isp0mryeKkIVIr4xe0K69ZT
Ez8FPxy5z+ViugAQjH7hxklZ+dmMKYqRikAXdsICwhQ6Muh5FpeLIITGTwPX3fQ9
AaYJCDIkWEyP+BrIxS6dCFViPYZdxSy1a1q+WE9CZjqEtzLksXwANRKMsdYO6efP
4cjR78yCg8a1Crn7wPKk
=3xbL
-----END PGP SIGNATURE-----
--96YOpH+ONegL0A3E--
- Raw text -