As usual, the quickest way to a solution is to make a fool of yourself in
public, and this time is no different.
AFAICT, at some point during setup of the autoloader, I ran `mt -f /dev/nst0
defblksize`, which changes the default block size for newly inserted tapes. It
seems that if you don't pass a block size to defblksize, the default value it
passes to the ioctl is 1... which happens to be a valid block size according to
this tape drive. This broken setting will persist until the next reboot unless
cleared.
So, reader from the future, if you got here from a search engine while trying
to figure out why you can barely get any wire throughput from your fast LTO
drive, check BlockSize in `tapeinfo -f /dev/nst0`, and if it's 1, try `mt -f
/dev/nst0 defblksize 0` and do an unload/load cycle.
- Dave
On Fri, Oct 15, 2021, at 01:31, David Anderson wrote:
> Hi all,
>
> I'm new to both bacula and tape storage, and wrestling with a strange issue:
> it seems my tape device resets its block size to 1 byte every time I insert a
> tape. Anyone seen this before, and know how to make it stop?
>
> In more detail: I have an HPE autoloader with an LTO-6 drive:
>
> > tapeinfo -f /dev/nst0
> Product Type: Tape Drive
> Vendor ID: 'HP '
> Product ID: 'Ultrium 6-SCSI '
> Revision: '35GW'
> Attached Changer API: No
> SerialNumber: 'HUJ6035G4U'
> MinBlock: 1
> MaxBlock: 16777215
> SCSI ID: 9
> SCSI LUN: 0
> Ready: yes
> BufferedMode: yes
> Medium Type: Not Loaded
> Density Code: 0x5a
> BlockSize: 1
> DataCompEnabled: yes
> DataCompCapable: yes
> DataDeCompEnabled: yes
> CompType: 0x1
> DeCompType: 0x1
> BOP: yes
> Block Position: 0
> ActivePartition: 0
> EarlyWarningSize: 0
> NumPartitions: 0
> MaxPartitions: 3
>
> I got both the changer and drive set up in Bacula, with Maximum Block Size =
> 512K, but in my initial btape speed tests I was only getting 13MB/s with
> random data, less than 10% of the theoretical throughput.
>
> After some futzing around, I figured out that the answer is in the tapeinfo
> output: BlockSize is set to 1, which I think means btape's writes end up
> being split into 1-byte blocks by something downstream (either the st driver
> or the drive firmware, not sure?)
>
> When I manually clear the block size with `mt -f /dev/nst0 setblk 0`, btape
> speeds jump to 130MB/s and everything's happy.
>
> Experimenting further, the block size seems to get reset to 1 whenever I load
> a new tape with mtx. As far as I can tell, mtx itself doesn't do any funny
> business with drive configuration.
>
> Anyone seen this behavior before? Is there some well-known knob that's not
> set correctly on my machine to consistently leave the block size up to the
> userspace software? If not, any suggestions on how to reset the block size on
> every tape load? So far my only plan is to make a custom mtx-changer that
> runs `mt setblk 0` on every load.
>
> Thanks in advance,
> - Dave
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
