From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sat, 10 Oct 2015 08:23:26 -0700 To: 9fans@9fans.net Message-ID: <8675dd67db7f50f93257f1df50e73767@lilly.quanstro.net> In-Reply-To: References: <385c85ca703ac8d441c4227d1bb24643@u2.inri> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] off topic - a good Git reference Topicbox-Message-UUID: 71ab8f6c-ead9-11e9-9d60-3106f5b1d025 On Wed Oct 7 14:25:58 PDT 2015, elbingmiss@gmail.com wrote: > Yes, it has no sense in Plan 9, I know, thanks. I was talking about ape lib > because is what was used to port git in my case. > > I even found a Rob's old mail answering a similar question saying that it's > a matter of file server (I can't remember original question). And there are > many debates around internet about fsync, with fans an detractors. > > In previous versions of git, there weren't fsyncs to freeze keys, but Linus > wanted to change old git behaviour at one moment, 1.8 version I think. And > after all, problem is still there in this case, there's no way to ensure if > an fd is in the heaven of bits or in any place in fs at the moment of fopen > issue by git, breaking its behaviour over Plan 9. so we have these facts 1. git worked without the fsync, 2. on plan 9, fsync is unnecessary yet, the agument is: because ape fsync, git is broken on plan 9? i'm afraid i don't understand this reasoning. also, directly to the "heaven of bits". i assume you mean the data in the file to which the fd points. all unix-like systems provide some consistency guarantees. if a file is manipulated by a single program on a single machine, there will always be a strongly coherent view of the file. perhaps there is some confusion between the system call interface, which uses file desciptors and stdio, which does do read and write buffering? fsync doesn't take care of that, either. in the case of system crash, fsync doesn't provide strong guarantees that the write will not be lost, or the fs not corrupted even in linux. some versions of the linux kernel do nothing on fsync, fsync doesn't actually put data on disk https://lwn.net/Articles/270891/ and some options for ext make fsyncs useless https://lwn.net/Articles/328363/ - erik