From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] 9p2k, fsync From: "rob pike" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-zniaqmsylltxfrcojzttasfzpf" Message-Id: <20010208062621.A6F2719A02@mail.cse.psu.edu> Date: Thu, 8 Feb 2001 01:26:19 -0500 Topicbox-Message-UUID: 5d51e0b2-eac9-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-zniaqmsylltxfrcojzttasfzpf Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit No one here said, ``the file server will take care of it''. What we're saying is that the file server must take care of it if anyone will. -rob --upas-zniaqmsylltxfrcojzttasfzpf Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Thu Feb 8 01:02:23 EST 2001 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Thu Feb 8 01:02:21 EST 2001 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.18.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 9014319A02; Thu, 8 Feb 2001 01:02:08 -0500 (EST) Received: from math.psu.edu (leibniz.math.psu.edu [146.186.130.2]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 16A89199ED for <9fans@cse.psu.edu>; Thu, 8 Feb 2001 01:01:28 -0500 (EST) Received: from augusta.math.psu.edu (augusta.math.psu.edu [146.186.132.2]) by math.psu.edu (8.9.3/8.9.3) with ESMTP id BAA00095 for <9fans@cse.psu.edu>; Thu, 8 Feb 2001 01:01:27 -0500 (EST) From: Dan Cross Received: (from cross@localhost) by augusta.math.psu.edu (8.9.3+Sun/8.9.3) id BAA04455; Thu, 8 Feb 2001 01:01:27 -0500 (EST) Message-Id: <200102080601.BAA04455@augusta.math.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] 9p2k, fsync Newsgroups: comp.os.plan9 In-Reply-To: <200102080115.UAA26741@smtp1.fas.harvard.edu> Organization: Mememememememmeme Cc: 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: Thu, 8 Feb 2001 01:01:27 -0500 (EST) In article <200102080115.UAA26741@smtp1.fas.harvard.edu> you write: >There are no asynchronous writes here. Define asychronous in this context. There are no asychronous network transactions, true, but that's not the same thing as an asychronous write >By the time the write(2) system call returns, >the file server has acknowledged receipt of the data. >At that point, it's the file server's business. Not really; if my application depends on that data being on stable storage, not just a RAM buffer, I could still be in trouble. The scenarios are obvious, but the point is that I might have a real need for this sort of thing, and ``the file server will take care of it'' isn't really good enough. >Fsync is simultaneously too much and too little. >People who care often care about making sure >individual blocks are committed to storage, and fsync >is the only hammer they have. When the file is modeled as a stream of bytes, ie, the blocks are abstracted away from me as the programmer, I'm not sure that hammer isn't the only one appropriate for the nails I'm given. >I'm sure that if there were a Tsync message in >the protocol, it would suffer the same problem. >Nine times out of ten it would be the wrong hammer. Yeah, I won't disagree with you there, but that doesn't make it any less useful. It's a choice between a hammer for both nails and screws, or using my hands for both. - Dan C. (Of course, I'd use a skateboard truck instead of my hands, but you get the idea. I had to do that once repairing a ramp. :-) --upas-zniaqmsylltxfrcojzttasfzpf--