Date: Tue, 19 May 1998 09:29:18 +0000 (GMT) From: Hans Huebner <hans@artcom.de> To: ken@plutotech.com, gibbs@plutotech.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Tape driver - What do we really want? Message-ID: <Pine.BSF.3.96.980519083410.20159D-100000@transrapid.artcom.de>
next in thread | raw e-mail | index | archive | help
Hello there, having thought about the tape subsystem for some time, I'm now trying to make up my mind on the changes which would be desireable. I will add most of the functionality suggested here to the CAM tape subsystem in the near future. Please comment on or add to my list, if you feel the need: * Fast locate support There should be a MTLOCATE operation in MTIOCOP which locates a given block address with the SCSI LOCATE command. This raises the question on how to interpret the data returned by the READ POSITION command (which would be used in MTIOCGET). The SCSI-2 draft specifies a reply format which is different from what the DLT and DDS2 drives I have support. The specification says that block addresses are two bytes long, which is obviously too short. Would we default to the modern format (four bytes for block addresses), or would we want to have quirks for drives which do not adhere to SCSI-2? A new mt subcommand, say 'seek', will be needed to locate a block position using the new MTIOCOP operation. * Implement MTIOCGET fully In particular, the current position should be read and returned (as discussed above). * Make 'mt status' print only the status Currently, 'mt status' prints the status and the permissible compression modes. This is not quite what I'd expect. I'd want to make 'mt status' output the current file number, block position (if available), block size, compression mode and a description of the current position (at BOT, at EOT, at File Mark, not at file mark). As it has been discussed in freebsd-scsi, the block size of the tape can only be determined by reading a block from the tape. Also, this number is valid only for the current block, as the block size may change on tape. Nevertheless, such a feature would be useful since most tapes are blocked at a fixed block size, and all the user wants is to know what option to specify to tar/cpio/restore/dd or whatever. * Create 'mt capabilities' command The permissible compression modes should be printable with a new subcommand to mt, maybe 'capabilities'. Along the way, the permissible modes of the tape should be made a list (contrasted to the four-mode scheme we currently have). While we are at it: I also think that having a more elaborate configuration for individual tape drives' capabilities would be desireable. As of now, FreeBSD/CAM is kind of 'naive' with respect to SCSI tape drives, and uses only the least common denominator of the capabilities individual tape drives have. What comes to mind are - Default block sizes for different types of drives - List of supported SCSI features (LOCATE support, compression etc.) - Timeouts for various operations (then again, maybe not) * Make mt work with remote tape drives The mt command should work with remote tape drives to the extent that the rmt protocol allows. This is needed to support media changer servers which, through a custom protocol, mount tapes at the request of applications running on other systems in the network. I'd strive for simplicity, of course. But then again, some features would really be helpful. Keep in mind that I am working on the CAM driver, not the old SCSI stuff. Your input is appreciated. Regards, Hans To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980519083410.20159D-100000>