Rene Arnhold <rene.arnhold <at> jena.de> writes:

> 
> sorry did not see this mail until now
> And sorry about the missleading LTO5 in my first toppic.
> We use LTO6 on the bareos Server.
> 
> i have configured the max blocksize in the device section of my tape
> drives. At the moment i have switched back to the default values and
> moved all written tapes to a new pool with the 1M blocksize.
> 
> HPs documentation about the LTO6 drives says, that you should not go
> after 256 KB blocksize
> (https://docs.oracle.com/cd/E38452_01/en/LTO6_Vol5_E1/LTO6_Vol5_E1.pdf).
> Saddly my Drives are IBM and I can not find writings from IBM about this.
> 
> Maybe there is something going on at the hardware on some drives and a
> btape fill will rise errors (sometimes) where btape test does not.
> 
> I will schedule a btape fill for tomorrow morning with the big blocksize
> to test this.

You can use the tapeinfo (from the mtx program) for my LTO4 on Solaris
that looks like this:

15:14 [root:corona][319] ~ > tapeinfo -f /dev/rmt/0ubn                     
                                                                           
                                                                           
                                         
Product Type: Tape Drive
Vendor ID: 'HP      '
Product ID: 'Ultrium 4-SCSI  '
Revision: 'U52U'
Attached Changer API: No
SerialNumber: 'HU1145KF03'
MinBlock: 1
MaxBlock: 16777215
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x44
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
Block Position: 8126794
Partition 0 Remaining Kbytes: 400308
Partition 0 Size in Kbytes: 400308
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 0

The Maxblock is quite a bit bigger then 1 Mb already for a LTO4
drive (HP b.t.w.)

Reading the manpage for the ST driver on Linux
(http://man7.org/linux/man-pages/man4/st.4.html) shows the following
for the EBUSY error:

EBUSY         The device is already in use or the driver was
              unable to allocate a buffer.

So its mostly a problem to allocate the larger buffers needed for
writing the bigger block sizes.

It also seems the maximum transfer size kind of depends on things
like the stack used e.g. SCSI driver, kernel etc.

The SCSI Generic howto has some info on this:

http://sg.danny.cz/sg/sg_io.html

See Maximum transfer size per command. That document is somewhat dated
but I wouldn't be surprised it still true.


-- 
Marco van Wieringen                   [email protected]
Bareos GmbH & Co. KG                  Phone: +49-221-63069389
http://www.bareos.com                     

Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer: Stephan Dühr, M. Außendorf, J. Steffens,
                 P. Storz, M. v. Wieringen

-- 
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to