Other [LTO tape drive] Increase si_iosize_max?

  • Thread starter Interesting Username
  • Start date
I

Interesting Username

Guest
Hello all,

I'm trying to get a tape drive running on my FreeBSD 11.1 system. The problem is that I ran into shoe-shining (tape drive constantly stopping and restarting) when using the standard block size with tar, so I tried to increase the block size to 256.

Therein lies the problem though. First I received an error that the request size is greater than MAXPHYS - so I recompiled the kernel with a bigger MAXPHYS - and now I'm running into the following error:

Code: 
request size=262144 > si_iosize_max=65536; cannot split request

Any idea on how to increase the value of si_iosize_max? And what are the consequences? (aka "What does the value do"?)

Thanks in advance.
 
Interesting Username said:
I'm trying to get a tape drive running on my FreeBSD 11.1 system. The problem is that I ran into shoe-shining (tape drive constantly stopping and restarting) when using the standard block size with tar, so I tried to increase the block size to 256.
Click to expand...
Which LTO generation, manufacturer, and firmware version? LTO does a pretty good job of coagulating records (blocks) - the internal on-tape format has flags for compression, encryption, actual user record length, etc. I'd suspect some sort of throughput limitation rather than a buffer size issue here.
Therein lies the problem though. First I received an error that the request size is greater than MAXPHYS - so I recompiled the kernel with a bigger MAXPHYS - and now I'm running into the following error:

Code: 
request size=262144 > si_iosize_max=65536; cannot split request

Any idea on how to increase the value of si_iosize_max? And what are the consequences? (aka "What does the value do"?)
Click to expand...
What controller is your drive connected to (again, model / manufacturer / firmware version)? This was fixed for many of the LSI controllers (mpr(4) and mps(4)) back in the FreeBSD 10 days. I have a much more detailed writeup here (scroll down to "Backups"), but basically there are a number of limitations. MAXPHYS defines the largest physical I/O size the kernel will handle. Different controllers may have limits that are smaller than MAXPHYS, and that's where si_iosize comes in - it is the device-independent representation of the largest physical I/O size the controller is willing to handle. Increasing it involves driver-specific work on each driver. Take a look at r303089 to see what was involved for the drivers listed above. Note that some controllers may simply not support larger physical I/O sizes.

There is one other harmless message - before passing the first user I/O to a tape, FreeBSD does a "taste test" by default (controlled by the SA_QUIRK_NODREAD quirk) and it does that with a small buffer, so you get a bogus "tape record bigger than supplied buffer" message. Once you realize this is the kernel's taste test buffer, you'll realize it is safe to ignore. Refer to this discussion for the gory details.
 
Terry_Kennedy said:
Which LTO generation, manufacturer, and firmware version? LTO does a pretty good job of coagulating records (blocks) - the internal on-tape format has flags for compression, encryption, actual user record length, etc. I'd suspect some sort of throughput limitation rather than a buffer size issue here.
Click to expand...

It's a HP StoreEver LTO-4 Ultrium 1760 drive connected via SCSI (so it's rather old but I got it for free...). I have no idea what version the firmware is running to be honest, any idea on how can figure that out?

Terry_Kennedy said:
What controller is your drive connected to (again, model / manufacturer / firmware version)?
Click to expand...

I'm using an Adaptec AHA-2940 PCI-SCSI controller card. Same problem concerning the firmware.

So you're telling me it's basically a hardware or driver issue if I understand you correctly?
 
Interesting Username said:
It's a HP StoreEver LTO-4 Ultrium 1760 drive connected via SCSI (so it's rather old but I got it for free...). I have no idea what version the firmware is running to be honest, any idea on how can figure that out?
Click to expand...
Ok. LTO4 maximum data rate is around 120MB/sec (at least for non-compressable data). Parallel SCSI is a bit of a stretch for this generation (LTO3 was the last generation where parallel SCSI was common, and I don't know of any LTO5 parallel SCSI drives).

For firmware, look in your /var/run/dmesg.boot file, like this:
Code: 
(0:120) gate:~terry# grep ^sa0 /var/run/dmesg.boot
sa0 at mps0 bus 0 scbus1 target 0 lun 0
sa0: <IBM ULTRIUM-HH4 G9N1> Removable Sequential Access SPC-4 SCSI device
sa0: Serial Number 106804xxxx
sa0: 600.000MB/s transfers
In the above example, the firmware is G9N1. That's an IBM-specific firmware and probably unrelated to whatever firmware your drive uses.
I'm using an Adaptec AHA-2940 PCI-SCSI controller card. Same problem concerning the firmware.
Click to expand...
[Adam Savage voice]Well, THERE'S your problem![/Adam Savage voice]
The 2940 is a 10Mbyte/sec card, according to the manufacturer's web site. So it can only provide data at 10% of the speed the drive wants it, best case.

If you really want to stick with a parallel SCSI tape drive, your best bet would be the AHA-29160 (least expensive) or AHA-29320 (HP recommended per this). In either case you will need new, 68-pin LVD SCSI cables. Note that your existing controller is PCI (plain old classic PCI), while some of the controller variants I listed above are PCI-X (which will work, assuming nothing on your motherboard interferes with the connector overhang). Some other variants are PCIe (don't you love the confusingly similar naming) which won't work in your system unless it has a PCIe slot in addition to its PCI slot.

Note that you're well past the curve of "mainstream" with this setup, and sliding closer to the cliff of obsolescence. If you're going to buy a new controller and cables, it might be time to think about SAS (you'll need a SAS drive as well).

Edited to fix typos
 
Last edited:
Ah, thank you!

Well, it was more an experiment than anything. I am aware that my setup is pretty much obsolete but I figured it was worth a try since I got the drive for free. I'll take a look at the SCSI controllers you named. Again, thank you very much for your input.

Terry_Kennedy said:
don't you love the confusingly similar naming
Click to expand...
Heh yeah... at least they're actually named differently and kind of easy to tell apart. That whole SCSI mess confuses me more to be honest, having never actually used it until now ("wrong generation" one might say) and trying to read through the bunch of different versions. Man, am I glad it's no longer the 90's ;D
 
Yeah.. SCSI is just one of those things that grew totally organically from its humble beginnings with no real control of what should be done and how, different vendors just went ahead with their solutions and tried to tell everyone else that their solution is now the new standard. About the only thing left now in real use is the high level command protocol that all OSes use as the high level API to abstract away the pecularities of the underlying transfer method (ATA/SATA/USB/etc.), especially when dealing with devices like CD/DVD -drives.
 
You must log in or register to reply here.
Back
Top