Date: Thu, 21 May 1998 14:41:29 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: hans@artcom.de (Hans Huebner) Cc: gibbs@pluto.plutotech.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Tape driver - What do we really want? Message-ID: <199805212041.OAA05585@panzer.plutotech.com> In-Reply-To: <Pine.BSF.3.96.980519083410.20159D-100000@transrapid.artcom.de> from Hans Huebner at "May 19, 98 09:29:18 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Hans Huebner wrote... [ sorry it took so long to reply. I'm including your entire message in my reply since I haven't seen it come across the scsi list yet ] > 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? Well, my copy of the SCSI-2 spec says that the block addresses are 4 bytes long. My guess is that you have the same copy of it, or something similar. Look carefully at the byte numbers in the left hand column of the read position data format diagram. The locate idea is a good one, though. > A new mt subcommand, say 'seek', will be needed to locate a block position > using the new MTIOCOP operation. Sure, that sounds like a good idea. > * Implement MTIOCGET fully > > In particular, the current position should be read and returned (as > discussed above). Yeah, sounds good. We might want to have two versions of the MTIOCGET ioctl -- one with all the bells and whistles (i.e. density, compression, etc.) and one that uses the "traditional" structure that other machines accessing a FreeBSD box via the rmt protocol would understand. The "traditional" structure does provide for sending current position information,t hough. > * 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). The current CAM mt command doesn't print out permissible compression modes, it prints out the current compression mode. It prints out either the compression algorithm (IDRC, DCLZ, etc.) in use, "disabled", or "unsupported". I would like to see 'mt status' continue to print out the density information. That can be useful at times. > 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. Yes, that would be useful. > * 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). Right. If we're going to have a list of things, we should make it dynamic, not a fixed size. > 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) I'm not sure adjustable timeouts are entirely necessary. It could be done, but I'm not sure how often people run into the situation that the default timeout is too short. > * 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. Sounds interesting...but if the media changer servers in question use a custom protocol, how is adding rmt support to mt going to help? > 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. The locate and read position support would definitely be helpful. You may want to take a look at the NetBSD implementations of those. Ken -- Kenneth Merry ken@plutotech.com 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?199805212041.OAA05585>