This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mt and tar fail on LTO-5 drives


On 8/19/2013 12:21 PM, 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.

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 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

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


I suppose there is nothing for cygwin to do, other
than adding some items to the 'density' list:
   {0x44, "Ultrium LTO-3"},
   {0x58, "Ultrium LTO-5"},

How do I best report this to Microsoft?
Any chance they fix it, you reckon?

First of all, it's not clear to me whether it is a Microsoft problem
or a device driver problem.  I would see what's known about the behavior
of the devices and their drivers with the specific Windows version you
have.  Of course it could be that other tools don't need to ask those
same questions, for some reason, so that they end up working fine ...

Regards -- Eliot Moss

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]