Slow FreeBSD tape access with Bacula?

A while back I migrated Bacula, along with my tape library, from a Linux machine to a FreeBSD machine. The FreeBSD server is a whitebox with a bunch of hard drives, and those + ZFS == 30 TB of backup space. Which is sweet.

This lets me try doing disk-to-disk-to-tape with Bacula. Mostly working, but one thing I notice is that it is damn slow getting to the end of a tape to append data when I want to migrate -- like, half an hour or more. This is way longer than the Linux machine ever took, and that's doubly weird because I moved over the FC cards with the migration so it's the same hardware (though perhaps different drivers). So WTF?

Turns out, I think, that this is a shortfall in FreeBSD. Follow the bouncing ball:

• Tape drives write one EOF (end-of-file) marker for the end of a file.

• Bacula writes its jobs in chunks -- I have it set up to write 8GB chunks -- and the tape driver marks each one with an EOF.

• When a tape is loaded, Bacula needs to get to the end of a tape. That means lots of "please look for the next EOF marker", which takes a while.

• There's a shortcut, though: the MTIOCGET ioctl can (I think) keep track of how many EOFs are on the tape. That means the driver can just tell the tape drive "please fast-forward to the nth EOF marker."

• Linux implements MTIOCGET.

• FreeBSD does not.

Now, this is all stuff I've put together from various mailing list posts, so I might be wrong...but it seems to explain what's going on. There's also a suggestion that I'm wrong about this -- that FreeBSD does support MTIOCGET. So much for conclusions. Stay tuned.