DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=EktESZCtm2wQfzEevwIR5ke6Q0ITTq3AoInB1yP9YOz
	tExLfHe8QE2zNBWsUpvWc5dDkReWEAio4ZplkuUDiWAQNUZiCJZmCbJHqF0VRCmT
	CcfvyzXqeBAHKfRhQedNZMpk6TDfe3LaPsx6A62tTbeJueSPUVo8rweaFqwGIGso
	=
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
Message-ID: <52124601.5000409@mailme.ath.cx>
Date: Mon, 19 Aug 2013 18:21:21 +0200
From: bartels <bartels AT mailme DOT ath DOT cx>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130704 Icedove/17.0.7
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: mt and tar fail on LTO-5 drives
References: <520FC274 DOT 3040001 AT mailme DOT ath DOT cx> <20130819101917 DOT GC18757 AT calimero DOT vinschen DOT de>
In-Reply-To: <20130819101917.GC18757@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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?

- Bartels.


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