From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 18 Dec 2008 19:54:42 -0800 From: Roman Shaposhnik In-reply-to: <80c8eabd9be7ed7c3d35f379b7f8007f@quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: <41C79A6A-3A01-4AD3-A73C-BFDA28439FE5@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <80c8eabd9be7ed7c3d35f379b7f8007f@quanstro.net> Subject: Re: [9fans] 9pfuse and O_APPEND Topicbox-Message-UUID: 6a2a57dc-ead4-11e9-9d60-3106f5b1d025 On Dec 18, 2008, at 7:43 PM, erik quanstrom wrote: >> Agreed. Now, here's a bit that I still don't quite >> understand: Plan9 does have DMAPPEND on >> a per-Qid basis. Why was it decided not to >> have it on a per-Fid basis (which would match >> POSIX semantics 100%)? >> >> The way I understand -- DMAPPEND is just a hint >> to the server to *alway* ignore the offset in >> incoming writes. It seems that ignoring offsets >> in writes for the Fids that asked for it wouldn't be >> much more difficult, would it? > > DMAPPEND, for servers that implement it, is not > a hint to the server, it's a write to the end of the file, > whatever offset that might be. Well, modulo clumsy wording on my part your explanation seems to be 100% the same as mine. > since the end is computed on the file server, multiple > concurrent writers don't cause a problem. since the > fs is in a position to serialize appends to the same > file. And where does it contradict the idea to have the equivalent of DMAPPEND set per-FID? Or more precisely per open-FID. Look, one way or the other the server has a *choice* of ignoring the offset in write(5) messages and always appending the data. It can do it effectively and safely (unlike the client). All I'm asking is why the obvious benefits of asking the server to ignore the offsets ONLY for a particular open fid were not considered to be a good thing. Your reply doesn't answer that question. Thanks, Roman.