Be careful, TK-50 is different than 9-track. It's a streamer tape like QIC, 4mm and 8mm. The blocking is done under the covers by the HW and the blovk size if just how a DMA is done. I recommend that you pre-fetch the read with dd or double-dd setting ibs=64k, obs=20b and conv=sync and pipe the output to the reader (tar/cpio or the like) [if that fails try obs=1b]. This should work well as can (TK-50 overall suck - don't set your hopes high on anything with them -- they were DECtape from a realiabilty standpoint, they were different from the reset of the world, the performance was poor and they were expensive).
Anyway, by using dd or the like a front end, it will allow the read streamer to read as fast as it can. The problem is that the way it works under the cover does not shine with traditional UNIX I/O. BTW: ibs of anything more than 64K on a VAX (or PDP-11) will not help because of the dma size on the Unibus caps DMA read/writes at 64K. On a PMAX or (under Tru64 on a Alpha), you can try using really large ibs sizes depending on your physical memory size.
BTW: What will help the most is actually finding a copy of the old double-dd program (from the UUNET archives) which forks off two child procees to perform the actual I/O and alternates between the two processes via pipe between them and controller - so one dd process is reading when the other dd process is writing. [It used to be called: ddd before the Gnu guys grabbed that name for the debugger]. The command line might be something like: ddd ibs=64k obs=20b | tar xvpf -
FWIW: I wrote a version of a fast dd years ago that used pthreads and a semaphore that I should still have kicking around. At one point when I was dealing with streamer tapes for backup, I definitely ran it on Tru64 and FreeBSD, but I've forgotten where Ultrix fell.