From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Cross Message-Id: <200102080601.BAA04455@augusta.math.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] 9p2k, fsync In-Reply-To: <200102080115.UAA26741@smtp1.fas.harvard.edu> Cc: Date: Thu, 8 Feb 2001 01:01:27 -0500 Topicbox-Message-UUID: 5d228100-eac9-11e9-9e20-41e7f4b1d025 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. :-)