From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] fs (config) questions From: forsyth@caldo.demon.co.uk MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-ywqfuosgisglcepeqaqyvqtupz" Message-Id: <20010413224351.96123199C0@mail.cse.psu.edu> Date: Fri, 13 Apr 2001 23:41:08 +0100 Topicbox-Message-UUID: 81d6ed06-eac9-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-ywqfuosgisglcepeqaqyvqtupz Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit each time i've considered that question (each time i've configured a new file server) i've eventually decided in favour of using the pseudo-worm driver. it isn't more resilient in the face of certain crashes but it might be slightly more likely to detect an inconsistency sooner rather than later (or at least more cleanly). i could be wrong but i suspect a few supporting commands rely on getting a read error for blocks not yet written (cwcmd prchain might be one). i'm glad i did keep the bitmap the last time, for another reason. the written-block bitmap also turned out to be quite useful when copying the existing structure to a real worm jukebox, since it said which blocks had actually been written, and helped to set precise limits for the copy. another useful hint when copying a pseudo-worm to a new file server with a real jukebox and a new set of cache discs with a different structure is to do cwcmd savecache on the file server, and {disk/exsort -w} before starting the copy. that way, cwcmd loadcache will reload the cache on the new file server with much less jukebox activity (and that's an understatement). --upas-ywqfuosgisglcepeqaqyvqtupz Content-Type: message/rfc822 Content-Disposition: inline Received: from finch-punt-12.mail.demon.net ([194.217.242.36]) by lavoro; Fri Apr 13 20:02:06 BST 2001 Received: from punt-1.mail.demon.net by mailstore for forsyth@caldo.demon.co.uk id 987185368:10:29236:0; Fri, 13 Apr 2001 18:09:28 GMT Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-1.mail.demon.net id aa1029108; 13 Apr 2001 18:09 GMT Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.8.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 6CD9B19A43; Fri, 13 Apr 2001 14:09:12 -0400 (EDT) Received: from smtp2.fas.harvard.edu (smtp2.fas.harvard.edu [140.247.30.82]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id AB674199E3 for <9fans@cse.psu.edu>; Fri, 13 Apr 2001 14:08:39 -0400 (EDT) Received: from plan9.cs.bell-labs.com (roam183-121.student.harvard.edu [140.247.183.121]) by smtp2.fas.harvard.edu with SMTP id OAA20972; Fri, 13 Apr 2001 14:08:39 -0400 (EDT) Message-Id: <200104131808.OAA20972@smtp2.fas.harvard.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] fs (config) questions From: "Russ Cox" 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.1 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: Fri, 13 Apr 2001 14:08:38 -0400 yes it is possible, but not quite that easy (yet). i've done it several times, using a specially-modified file server kernel to initialise the bitmap for the pseudo-worm area (after that the normal code is happy to include and write to the extended space). is there a reason to use the pseudo-worm driver at all? as far as i could tell, it's just making sure that blocks don't get written twice. that's important, i guess, assuming the cached worm driver is debugged, i'd expect to be able to use `cw1w2' to the same effect as `cw1fw2' except that the former doesn't have the bitmap and thus can be lifted from one disk onto another without a special kernel. am i missing something? (probably.) russ --upas-ywqfuosgisglcepeqaqyvqtupz--