Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 31 Oct 2014 12:51:40 +0100
From:      Stefan Huerter <maulwurf@guckux.de>
To:        freebsd-stable@freebsd.org
Subject:   Re: LSI 1030 and LTO-3 won't work
Message-ID:  <545377CC.8060706@guckux.de>
In-Reply-To: <20141009034819.GA30406@mithlond.kdm.org>
References:  <54358D99.5090403@guckux.de> <20141009034819.GA30406@mithlond.kdm.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Guckux

It seems, the problem was the syntax and wrong device.
I've set the default tape-device in the env as TAPE=/dev/nsa0
I've set the blocksize before via
mt blocksize 0 -> using /dev/nsa0

So, since I set the blocksize with:
mt -f /dev/sa0 blocksize 0
it works


could this really be so?

Bye
   Stefan

On 10/09/14 05:48, Kenneth D. Merry wrote:
> On Wed, Oct 08, 2014 at 21:16:41 +0200, Stefan Huerter wrote:
>> Guckux
>>
>> I have problems with following configuration:
>> FreeBSD whisky 10.1-RC1 FreeBSD 10.1-RC1 #0 r272711M: Tue Oct  7,
>> LSILogic 1030 Ultra4 Adapter
>> Sun StorEdge C2 - LTO-3 library
>>
>> I've included the mpt-module to load at boot time in loader.conf.
>>
>> part from dmesg:
>> mpt0: <LSILogic 1030 Ultra4 Adapter> port 0xc400-0xc4ff mem
>> 0xff9a0000-0xff9bffff,0xff980000-0xff99ffff irq 23 at device 2.0 on pci5
>> mpt0: MPI Version=1.2.14.0
>> mpt1: <LSILogic 1030 Ultra4 Adapter> port 0xc800-0xc8ff mem
>> 0xff9c0000-0xff9dffff irq 20 at device 2.1 on pci5
>> mpt1: MPI Version=1.2.14.0
>>
>> (sa0:mpt0:0:5:0): 32768-byte tape record bigger than supplied buffer
>> (sa0:mpt0:0:5:0): 32768-byte tape record bigger than supplied buffer
>>
>> I've tried to resize the blocksize to 10240 via mt blocksize 10240.
>>
>> Nothing works - dump and tar...
>> dump reports shortly, that the End of tape is detected, tar reports
>> "write error".
>>
>> With the same controller no Problem with Backup Exec under Windows, or
>> Solaris with EMC networker.
>>
>> Hugh?
>> Any hints for me? Or can I give you some other informations, which you need?
> The error messages above usually indicate that you're trying to read a
> block from the tape (in this case a 32K block) that is bigger than the
> blocksize that you specified.  But it can also happen on a write to a tape
> when you're in fixed block mode and you try to write less than the
> blocksize.
>
> What does 'mt status' show?  If it shows 32KB blocks, then that may be your
> problem.
>
> What blocksize are you using with tar and dump?  (I believe they default to
> 10240 bytes.)
>
> It's generally easier to run in variable blocksize mode.  You can specify
> variable blocksize with 'mt blocksize 0'.  You can verify which mode you're
> in with 'mt status'.  For instance, this tape drive is in variable block
> mode:
>
> Mode      Density              Blocksize      bpi      Compression
> Current:  0x5a:LTO-6           variable       384607   0xff
> ---------available modes---------
> 0:        0x5a:LTO-6           variable       384607   0xff
> 1:        0x5a:LTO-6           variable       384607   0xff
> 2:        0x5a:LTO-6           variable       384607   0xff
> 3:        0x5a:LTO-6           variable       384607   0xff
> ---------------------------------
> Current Driver State: at rest.
> ---------------------------------
> File Number: 0  Record Number: 0        Residual Count -1
>
> I would try something like this:
>
> mt rewind
> mt blocksize 0
> mt status
> (verify that it says variable block mode)
> dump -C 16 -b 64 -0ua -f /dev/nsa0 /
>
> That specifies:
>  - 16MB read cache size (for reading the disk)
>  - 64K output blocksize
>  - level 0 dump
>  - update /etc/dumpdates
>  - write until the end of tape
>  - use the non-rewound tape device
>  - dump the root partition
>
> It is generally better to write to the tape drive with the largest
> blocksize that your tape drive and controller support.  You'll get better
> throughput that way.
>
> The tape driver in FreeBSD 10 will not allow you to read or write a
> blocksize that your drive and controller don't support.  To see what they
> support, try:
>
> sysctl kern.cam.sa.0
>
> maxio is the what we think you can effectively write given the limits of
> the system and the controller.  cpi_maxio is what the controller claims to
> support.
>
> Ken




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?545377CC.8060706>