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
