From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <73665946363e2389a4b708ad082a7811@plan9.escet.urjc.es> From: Fco.J.Ballesteros To: 9fans@cse.psu.edu Subject: Re: Re[2]: [9fans] diskless boot of one terminal off kfs machine In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-ozbxlovmxazdxxhvrjifmbihpn" Date: Wed, 5 Feb 2003 17:33:12 +0100 Topicbox-Message-UUID: 4f06cbd8-eacb-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-ozbxlovmxazdxxhvrjifmbihpn Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit That might be the reason it works fine here, then. I run just one fossil to service several partitions. --upas-ozbxlovmxazdxxhvrjifmbihpn Content-Type: message/rfc822 Content-Disposition: inline Received: from mail.cse.psu.edu ([130.203.4.6]) by aquamar; Wed Feb 5 17:05:25 MET 2003 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.30.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 102551998A; Wed, 5 Feb 2003 11:05:08 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from plan9.cs.bell-labs.com (ampl.com [204.178.31.2]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 88DF519A02 for <9fans@cse.psu.edu>; Wed, 5 Feb 2003 11:04:24 -0500 (EST) Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Wed Feb 5 11:04:23 EST 2003 Received: from 141.154.233.28 ([141.154.233.28]) by plan9; Wed Feb 5 11:04:21 EST 2003 Message-ID: To: 9fans@cse.psu.edu Subject: Re: Re[2]: [9fans] diskless boot of one terminal off kfs machine From: "Russ Cox" In-Reply-To: <3658374261@snellwilcox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Wed, 5 Feb 2003 11:04:26 -0500 > What was strange was the slow speed of the mkfs | mkext. forsyth pointed out to me that if you run mkfs | mkext with the source and destination on the same physical disk, it's likely to be quite slow because kfs and fossil will fight over the disk, causing a lot of seeking. it should be much faster to run mkfs >/file/on/other/disk mkext