From owner-freebsd-hackers Tue Mar 21 21:23:16 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA21588 for hackers-outgoing; Tue, 21 Mar 1995 21:23:16 -0800 Received: from ns.gte.com (ns.gte.com [132.197.8.9]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA21581 for ; Tue, 21 Mar 1995 21:23:14 -0800 Received: by ns.gte.com (8.6.10/8.6.10) id AAA16300; Wed, 22 Mar 1995 00:20:51 -0500 Received: from bunny.gte.com(132.197.8.1) by cliff via smap (V1.3) id sma016292; Wed Mar 22 00:20:27 1995 Received: by bunny.gte.com (8.6.9/GTEL2.19) id AAA02736; Wed, 22 Mar 1995 00:22:03 -0500 Received: by genesis.tiac.net (8.6.9/genesis0.0) id AAA06755; Wed, 22 Mar 1995 00:15:44 GMT Date: Wed, 22 Mar 1995 00:15:44 GMT From: steve2@genesis.tiac.net (Steve Gerakines) Message-Id: <199503220015.AAA06755@genesis.tiac.net> To: freebsd-hackers@FreeBSD.org Subject: Re: Problems with 2940 and 950210snap Sender: hackers-owner@FreeBSD.org Precedence: bulk > > Exactly what do you mean by that? I have been hacking a FULLY QIC compat > > backup/restore [i.e., QIC-40/80, and 113 style filesets] program for some > > time now for FreeBSD. Would such a change in any way effect my work? I plan on keeping the ioctl()'s to directly read and write tape segments around so your backup/restore program should still work. I started writing a backup program myself but I never finished it. If you'd like the source drop me a note and I'll send it off. > I mean that having both a device driver (/dev/ft0) and a special > user-agent for dealing with it (ft) violates the UNIX principle of > least surprise. I should be able to do: > > tar cvf /dev/ft0 > > And have it just work. The fact that /dev/rst0 and /dev/rmt0 both do > this only leads the new user further down the garden path. This is in progress, and it has some advantages and disadvantages. On the positive side, usage will be consistent with other tape drives. Since ECC support is moved into the driver, I can now perform some low level error recovery that the current driver is unable to do. While I'm in doing this stuff I'm trying very hard to eliminate the strange state machines within the driver as well. On the negative side, the driver is going to be much larger than it currently is. I also expect that the tape drive will not stream very well. (Ages ago the driver used strategy() for its work instead of ioctls and performed poorly, but this may have improved.) The last drawback is that with tar or dump you lose the ability to random access files on the tape. A QIC-40/80 backup program does this by storing the entire file directory at the front of a saved set. > Actually, I think if you do a tar cvf /dev/ft0 at this point you will > panic your system! Not quite user-friendly enough yet! :-) I'll have to check this in 2.0. On my 1.1.5 system I just get I/O errors. I do have some questions about what some correct magtape behaviors are, so if someone familiar with wt and st would raise their hand I would be grateful. :-) One concern I have is regarding tape length. It looks like dump wants to calculate the tape length in advance to avoid reaching end of media. QIC-40/80 tape drives have a variable number of blocks, depending upon how many have been marked bad, so how would I get a decent length? Is it a problem for dump to just fall off the end of the tape? - Steve steve2@genesis.tiac.net