Date: Wed, 8 Mar 95 9:51:18 MST From: terry@cs.weber.edu (Terry Lambert) To: joerg_wunsch@uriah.heep.sax.de Cc: henryk@gaja.ipan.lublin.pl, freebsd-bugs@FreeBSD.org Subject: Re: QIC-80 problem Message-ID: <9503081651.AA00888@cs.weber.edu> In-Reply-To: <199503080658.HAA02015@uriah.heep.sax.de> from "J Wunsch" at Mar 8, 95 07:58:33 am
next in thread | previous in thread | raw e-mail | index | archive | help
> As Terry Lambert wrote: > > > > > 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. > > > 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. > > [A very long explanation deleted.] > > Terry, you might sometimes look as well at the recipient address. > This one ended up in .pl, so i'm afraid your fine explanation might be > a bit hard to understand... (it's even hard to understand for me, even > after following this list for a long time now). Never underestimate your audience. 8-). If nothing else, I put the meat first: precompress the data. Even if you are right and he can't understand the whole thing except as broad strokes, he can see that. Actually Vadim Antonov (Saw him on "The Internet Show" last night, 'crushing the coup against Gorbachev', they said...) who now works for SprintNet wrote the BSDI ft driver and resolved most of the issues. Since he was laid off over the lawsuit, maybe he'd rewrite the free driver if someone asked nicely. > But speaking of double-buffering, it should be possible to solve the > problem by piping it through a program called ``team'', since it does > N-buffering. > > Why did nobody make a FreeBSD port for ``team'' by now? ;-) Because team just compiles up, mostly. One drawback, though: team make some assumptions about signals and pipes that are bad. While it is higher performance than ddd when it works, you could argue that it isn't even writen in C. 8-). The problems with its assumptions manifest on MP Sun machines, among others, by causing "broken pipe" messages instead of dumping output. In any case, team is insufficient for the same reason the ft filter isn't working, which is that the ft driver require that the program that is writing to it get its process quantum sufficiently frequently that it doesn't miss it's smallest timing window (subquanta). When then compression is done, system loading is such that the ft program doesn't get to do its thing (team would not either -- all it does effectively is interleave the I/O, something a single process async I/O program could do). When that happens, the driver fails to hit the window and the tape loses sync. Actually, a filter that used multiple outstanding async reads and used async writes to dump the data would probably have significantly higher performance than team because it would avoid context switching. Anyone? I want credit in the comments. 8-). I suggest "super team" so it can have a cool name like "steam". 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?9503081651.AA00888>