Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site watcgl.UUCP Path: utzoo!watmath!watcgl!dmmartindale From: dmmartindale@watcgl.UUCP (Dave Martindale) Newsgroups: net.unix-wizards Subject: Re: How to make 4.2BSD ``/etc/dumps faster Message-ID: <884@watcgl.UUCP> Date: Fri, 4-Jan-85 00:13:29 EST Article-I.D.: watcgl.884 Posted: Fri Jan 4 00:13:29 1985 Date-Received: Fri, 4-Jan-85 05:15:30 EST References: <6894@brl-tgr.ARPA> Reply-To: dmmartindale@watcgl.UUCP (Dave Martindale) Organization: U of Waterloo, Ontario Lines: 20 In article <6894@brl-tgr.ARPA> chris@maryland (Chris Torek) writes: >I figured pipes would be fairly slow 'cause the network interface >limits you to 2048 bytes per transfer (although you can increase >it). This means that for a 10240 block write (like dump() uses) >you need 5 pairs of context switches, which can beat a 750 into >the ground pretty well. Also, it makes it harder to communicate >success/failure statuses. > Passing *data* though the pipes would indeed be slow. But I suspect that the original author did the same thing I did for a general double-buffered block copy routine: have two processes, one reading and writing even-numbered blocks and one doing odd-numbered ones, and using pipes only for synchronization to make sure that the reads and writes occur in the correct logical sequence (in case either input or output is a tape drive). Actually, the one-byte values passed around via the pipes can also encode various types of special conditions, to ensure that one process quits when the other detects an EOF or error for example. You can come quite close to making the program behave like it was a single process that just overlaps reads and writes.