From owner-freebsd-current Mon Nov 15 16:12:26 1999 Delivered-To: freebsd-current@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 181D814ECC for ; Mon, 15 Nov 1999 16:12:21 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id QAA16389; Mon, 15 Nov 1999 16:12:08 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199911160012.QAA16389@gndrsh.dnsmgr.net> Subject: Re: FreeBSD 4.0 SCSI Tape Driver In-Reply-To: from Matthew Jacob at "Nov 15, 1999 03:57:49 pm" To: mjacob@feral.com Date: Mon, 15 Nov 1999 16:12:08 -0800 (PST) Cc: rb@gid.co.uk (Bob Bishop), current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Okay- I hear you both. > > What do you do with QIC drives which cannnot write 2FM then? Can you give me a model of a QIC drive that has the ``can't write 2 FM's'' and I'll see if I can find one so that I can see this problem first hand and propose a solution to it. I find it extreamly hard to beleive that you can't write 2 FM's, since that has been the standard logical EOT marker on mag tape as far back as I go, and thats to the late 60's and things like 200BPI 1/2 tape drives. It may be a mixing of the other problem, in that the drive already does write 2 FM and backspaces over one of them, if the drive does that and you try to write another one it creates 3 fm's in a row, and that may be a problem. For Bob, I'll note that leaving only a single FM at logical EOT on a tape will never causes data loss, you would just be able to read some trashed data on certain tape drives (namily drives that do not have an offset erase head) after the real data. In no way is anyones data at risk by not doing the double FM for logical EOT. The tcopy command may end up copying a whole pile of useless data is a concern though... For Matthew, the blank check area that you say will always be there is not correct, it depends on the tape transport design. Only tape drives with offset or seperate erase heads will have this condition. This it would be there for all forms of DAT, or for that matter helican scan tape drives in general, and missing for most forms of QIC, or Serpintine tape drives. > > > On Mon, 15 Nov 1999, Bob Bishop wrote: > > > Hi, > > > > At 11:01 am -0800 15/11/99, Matthew Jacob wrote: > > >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 have access to a few assorted drives and I'll do the experiments but > > don't hold your breath. > > > > BUT I have to say that on principle I'm with Rod on this one: EOF != EOT > > and mixing them up is a recipe for (inter alia) finding you can't read back > > dumps when you need them. > > > > > > -- > > Bob Bishop (0118) 977 4017 international code +44 118 > > rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > > -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message