Solved Can FreeBSD Serve Tape Drives as iSCSI Targets?

Sir Wuffleton

New Member

Reaction score: 1
Messages: 2

Some background on my environment and use case:
I would like to share my LTO5 tape drive via iSCSI with a server that will be doing backups to tape, but having the tape drive in a more convenient location to switch out tapes. The FreeBSD box is running pfSense and acting as a router (however, I have been using vanilla FreeBSD 10.3 in order to troubleshoot this). Changing the OS on this box or moving the server aren't really viable options for me, so as a newbie to FreeBSD, I'd really love to have some sort of native/supported solution to this if possible before I investigate other, less desirable options.

I haven't been able to find a lot of discussion on tape drives + iSCSI under FreeBSD, but from what I understand in ctl.conf(5), Direct (Type 0), Processor (Type 3), and CD/DVD (Type 5) are the only supported target modes. Sure enough, when I set any of those device types on the LUN, my Linux iSCSI initiator will only see it as one of those three - not a tape drive.

Upon further research, it looks like tape drives are type 1 SCSI peripherals, so at least in its current state, from my understanding, CTLD has no way to work with them (and when I try to force it, it unsurprisingly kernel panics).

My question boils down to: Is there currently any supported way to serve sequential/tape type iSCSI LUNs from FreeBSD 10.3, or am I out of luck?
 
Last edited:
OP
OP
Sir Wuffleton

Sir Wuffleton

New Member

Reaction score: 1
Messages: 2

Maybe the old userspace iSCSI target daemon can export tape drives as iSCSI targets.
It definitely can, though figuring out how to configure it was mildly painful, istgt seems to be able to handle physical tape drive targets without an issue (with very acceptable performance).

While it does work, the fact that it's depreciated leaves me a little concerned as to how long-term of a solution it'll be. But since it seems to be the only way to handle tape drives at the moment, I'd imagine it's probably the best solution until the native iSCSI stack adds support for more types of LUNs.
 
Top