From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] dumb question Message-ID: <20020627115912.S7017@cackle.proxima.alt.za> References: , Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from Andrew Stitt on Thu, Jun 27, 2002 at 09:17:01AM +0000 Date: Thu, 27 Jun 2002 11:59:12 +0200 Topicbox-Message-UUID: bb7b61e4-eaca-11e9-9e20-41e7f4b1d025 On Thu, Jun 27, 2002 at 09:17:01AM +0000, Andrew Stitt wrote: > > ... > im arguing about the apparent acceptance of a solution which wastes > resources, sure its 30k, but you can do quite a bit with 30k. and if you > actually have lots of users, things start to slow down. point im trying to > make: tar|tar uses more memory and resources then a recursive copy, ive > thoroughly explained this many times. whats so hard to grasp here? The penalty each instance of cp would have to pay if it included directory descent logic would be paid by every user, every time they use cp, while being used only a fraction of the time. Does it not make sense to leave the logic in tar, where it gets used under suitable circumstances and omit it in cp (and mv, for good measure and plenty other reasons)? There are additional benefits in using the piped approach, as mentioned, in that the two processes can run concurrently and therefore exploit any idle cpu opportunity. The two images will share text memory, and the system will manage the pipe between the two processes instead of dealing with possibly suboptimal memory allocation in a single program. Using DMA at the user level sounds like a major burden to me, and hardly portable. My understanding of memory mapped I/O is even more frightening. Has anyone ported cpio to Plan 9? Its "p" mode would give us an indication of costs. I note, for Andrew's benefit, that recursive operation of cp is recent, in relative term, whereas find | cpio -p goes back to smaller memory footprint machines. Something tells me that recursive cp is more greedy of resources than its predecessors. I could be mistaken, of course. ++L