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
