Re: mt and tar fail on LTO-5 drives

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

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?
> 
> Thanks for your time.
> 
> I did have a look.
> The size reported to mt by the os seems to be the root cause: it is 38_247_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 = 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");
 }
 
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):
> 
>  + 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
> 
> mt reports matching capacity, remaining and block:
> 
>  $ 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)
> 
> 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

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

Attachment: pgpUKO0Pv2Qpj.pgp
Description: PGP signature