Date: Mon, 30 Mar 1998 10:41:46 -0800 From: Matthew Jacob <mjacob@feral.com> To: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> Cc: Wilko Bulte <wilko@yedi.iaf.nl>, scsi@FreeBSD.ORG Subject: Re: SDT-7000 and other DDS-2 tapes Message-ID: <351FE76A.5778EA38@feral.com> References: <199803301820.LAA28310@narnia.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Justin T. Gibbs wrote: > > > I've always wondered if this is something the tape driver could recover > from. I guess if the tape driver is recording partion, FM, and block > count as it writes and the target drive allows block level repositioning > that it could recover. Do all tape drives lose their position on a > reset? How many support the soft reset alternative? I guess it's time > to do some experimentation. Only attempt this if the tape is being read. Even then, it's iffy. It depends really on whether, during reset conditions, you can really believe the tape in the drive is the same one you had. My take is that this is not something that the driver layer should do. This is something that a higher level should ascertain, since only it has knowledge of the information encoding. I would strenuosly argue that it'd better to figure out a much more robust error return mechanism (something a la r/w -> EIO (error state latches) -> MTIOCGETERR, releases latch returns error associated with EIO | -> rw, error message to console, releases latch ) and fix the utilities to deal with this (and the filesystems to deal with similar for removable media disk like devices). Drivers that attempt to be too smart can often lead to data destruction and application termination. I cannot think of a surer route to condemning the OS this happens on than going this way. (This issue has been bandied about at Sun very hotly over the last month or so) -matt 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?351FE76A.5778EA38>