Date: Tue, 7 Mar 95 9:43:56 MST From: terry@cs.weber.edu (Terry Lambert) To: henryk@gaja.ipan.lublin.pl (Henryk Sobczuk) Cc: freebsd-bugs@FreeBSD.org Subject: Re: QIC-80 problem Message-ID: <9503071643.AA24708@cs.weber.edu> In-Reply-To: <199503071032.LAA00257@gaja.ipan.lublin.pl> from "Henryk Sobczuk" at Mar 7, 95 11:32:11 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I have a 486/66 with FreeBSD. > I just bought a QIC 80 streamer and ftp'd an ft filter. > It works quite well with tar but only with "B" option. > When i try to use a "z" option for tar it hangs after > some time. > > It would be nice to tar data in a compressed form. > > Is there anybody who knows how to deal with it? Precompress the data. Since the interface used by floppy tape drives is the floppy disk controller, and since the floppy disk controller does not have a buffer (or a detectable one, if you lucked into one of the new chips that almost no one uses) this means that it is sensitive in the extreme to missed I/O. The additional overhead of running the compressor gives it the opportunity to miss a communications window, and bam, you are screwed. If you want commpressed data on the tape, you must not try to compress it at the same time. Alternately, the kernel timer code, if used for an outcall on a retriggerable one shot, could be used to drive the floppy tape effectively in real time as a logical kernel thread at timer interrupt level. This would require fixing some timer issues that nobody agrees with me that they should be fixed and rewriting the floppy tape driver about 20%. If in the process, you added a 16k double buffer from user space, you would effectively close the 20ms and 200ms timing windows on getting commands to the tape drive in time, and you would probably be ominated for godhood (but since only 35% of all tape drives on UNIX class machines are floppy tapes, you'd probably lose out to Julian and Peter, who have been doing the SCSI stuff). Utilizing fixed timer code would mean that the driver would not need to buzz-loop to hit acceptable timing on the 20ms window, and would not depend on the user space process accessing the device within 20 full quanta (your compression problem) to hit the 200ms window. Closing the timing window using double buffering so you can repeat a write command instead of streaming if data is unavailable means that sometimes you wouldn't stream, but that's better than screwing up. Anything that works is better than anything that doesn't. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503071643.AA24708>