From owner-freebsd-current Tue Nov 16 7:15: 6 1999 Delivered-To: freebsd-current@freebsd.org Received: from yana.lemis.com (yana.lemis.com [192.109.197.140]) by hub.freebsd.org (Postfix) with ESMTP id 697C914CC4 for ; Tue, 16 Nov 1999 07:14:52 -0800 (PST) (envelope-from grog@mojave.sitaranetworks.com) Received: from mojave.sitaranetworks.com (mojave.sitaranetworks.com [199.103.141.157]) by yana.lemis.com (8.8.8/8.8.8) with ESMTP id BAA22288; Wed, 17 Nov 1999 01:44:36 +1030 (CST) (envelope-from grog@mojave.sitaranetworks.com) Message-ID: <19991115233605.10530@mojave.sitaranetworks.com> Date: Mon, 15 Nov 1999 23:36:05 -0500 From: Greg Lehey To: mjacob@feral.com, "Rodney W. Grimes" Cc: current@FreeBSD.ORG Subject: Re: FreeBSD 4.0 SCSI Tape Driver Reply-To: Greg Lehey References: <199911151857.KAA15544@gndrsh.dnsmgr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from Matthew Jacob on Mon, Nov 15, 1999 at 11:01:05AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 15 November 1999 at 11:01:05 -0800, Matthew Jacob wrote: > > > On Mon, 15 Nov 1999, Rodney W. Grimes wrote: > >>> >>> Reread/reresponse, sorry- ENOCOFFEE: >>> >>> >>>>> >>>>> 1 filemark can not be used for EOT, it is EOF, you can't tell if what you >>>>> read next is another file or not that may have been left by a previosly >>>>> longer usage on the tape. >>>>> >>> >>> >>> Well, read until *BLANK CHECK* seems to be what the driver can and should >>> do. Let me ponder this some- I believe what I propose actually works fine >>> for all the devices we currently support (hell, I use it all the time >>> myself). If you can provide an actual example of a SCSI tape device that >>> if you take FreeBSD-current or FreeBSD-3.3 and do a 'mt seteotmodel 1' on >>> and *not* be able to detect EOT, let me know! >> >> You won't get ``blank check'' if the tape has previosly been written >> past where you just finished writing. Instead you often get trash. > > Sorry, no. When you write a tape with these devices there's always a > leading erased area. That's why if you overwrite the front a tape you > can't skip past this area to recover data you really need. A misfeature of > modern technology. Is this anchored in the standards? What about DLT? What about future drives? I certainly wouldn't rely on anything that isn't guaranteed to stay that way. What happens if I write a tape on FreeBSD and read it in on System V? >> In your other message you talk about the driver getting 2 residuals >> in a row, well, unless you write the 2 EOF's you won't always get that... >> depends on if the tape drive does it automagically (which many newer >> drives do, they write 2 eof's and backspace over 1 of them for you when >> ever you tell them to write EOF, the drive itself uses 2 EOF's to >> determine logical EOT :-)). > > I repeat what I said in other mail- can you actually show me a tape drive > where what I propose really doesn't work? I think this question is the wrong way round. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message