From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <1b018dfb0698e455458b9cdfa9614bea@plan9.escet.urjc.es> To: 9fans@cse.psu.edu Subject: Re: [9fans] plan 9 ports to unix (including libdraw) From: Fco.J.Ballesteros In-Reply-To: <69c060565669c0bac7bc531ec3e40ddf@vitanuova.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-lpqexevptsxxagoiuhxgtpuhco" Date: Tue, 21 Oct 2003 19:11:47 +0200 Topicbox-Message-UUID: 765e25d6-eacc-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-lpqexevptsxxagoiuhxgtpuhco Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit There's no disagreement b/w you two. Our terminals are diskless, so a Twrite was already made and probably you also got your Rwrite (because you saw the buffer status changed in acme); a reset suffices. Of course, the file server is a world appart, and we halt it prior to reset (we do the same for local fossils on terminals). --upas-lpqexevptsxxagoiuhxgtpuhco Content-Type: message/rfc822 Content-Disposition: inline Received: from mail.cse.psu.edu ([130.203.4.6]) by aquamar; Tue Oct 21 18:03:43 MDT 2003 Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id 8620419A06; Tue, 21 Oct 2003 12:03:37 -0400 (EDT) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.20.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id D84FE19A1C; Tue, 21 Oct 2003 12:03:16 -0400 (EDT) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id BD4DA1998A; Tue, 21 Oct 2003 12:02:42 -0400 (EDT) Received: from rapido.vitanuova.com (unknown [62.254.170.97]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 578B119A21 for <9fans@cse.psu.edu>; Tue, 21 Oct 2003 12:02:30 -0400 (EDT) Message-ID: <69c060565669c0bac7bc531ec3e40ddf@vitanuova.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] plan 9 ports to unix (including libdraw) From: C H Forsyth In-Reply-To: <88d8e2add78e9f08ceaa62a7f8bcb2bc@plan9.escet.urjc.es> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-qgpxuxhaidftayxugaqchsrbiq" 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: Tue, 21 Oct 2003 17:05:28 +0100 X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) This is a multi-part message in MIME format. --upas-qgpxuxhaidftayxugaqchsrbiq Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit whether it's RS6000 with JFS, Linux, log-structured file systems or fossil, unless writes are write-through to disc, if you simply reset the machine, i'd expect you stand a good chance of losing data you've written just (ie, instantly) before the reset (unless the system somehow intercepts the reset). the systems might use one or more of journalling, soft-writes, or ordered writes to ensure the logical consistency of the stored file system data and metadata, if the system is interrupted at arbitrary points. but nevertheless, unless they buffer all modified data through intermediate NVRAM that they pick up after a boot, that's just the consistency on storage, and you'll lose whatever doesn't get to disc before the reset (or if the device can't write it before power fails). it might check cleanly, because the metadata is consistent, but a file is empty! --upas-qgpxuxhaidftayxugaqchsrbiq Content-Type: message/rfc822 Content-Disposition: inline Return-path: <9fans-admin@cse.psu.edu> Received: from punt-3.mail.demon.net by mailstore for forsyth@vitanuova.com id 1ABx5p-0006LI-Bk; Tue, 21 Oct 2003 14:02:38 +0000 Received: from [130.203.4.6] (helo=mail.cse.psu.edu) by punt-3.mail.demon.net with esmtp id 1ABx5p-0006LI-Bk; Tue, 21 Oct 2003 14:02:37 +0000 Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id 763C519A32; Tue, 21 Oct 2003 10:02:32 -0400 (EDT) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.16.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 74E3019A88; Tue, 21 Oct 2003 10:02:17 -0400 (EDT) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id E690E19A84; Tue, 21 Oct 2003 10:01:35 -0400 (EDT) Received: from nanionic.dat.escet.urjc.es (gsyc106.dat.escet.urjc.es [193.147.71.106]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id EDEBD19A02 for <9fans@cse.psu.edu>; Tue, 21 Oct 2003 10:01:23 -0400 (EDT) Message-ID: <88d8e2add78e9f08ceaa62a7f8bcb2bc@plan9.escet.urjc.es> To: 9fans@cse.psu.edu Subject: Re: [9fans] plan 9 ports to unix (including libdraw) From: paurea@plan9.escet.urjc.es In-Reply-To: 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: Tue, 21 Oct 2003 16:01:20 +0200 X-Spam-Status: No, hits=-0.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) > I do not totally agree with some of the linux comments I have seen here. > My experience is that Plan 9 file systems are less reliable than linux > file systems, and both of these are less reliable then freebsd, and none > of them compare to AIX JFS from 1991. In 1991, to reboot an RS/6000 AIX > machine running JFS, you just hit reset. You never lost a file. We use fossil here. On your terminals you can just reboot. I have never lost a file and find if the most reliable system I ever saw (snapshots make it even user-proof). I cross my fingers anyway... Gorka --upas-qgpxuxhaidftayxugaqchsrbiq-- --upas-lpqexevptsxxagoiuhxgtpuhco--