Re: [9fans] off topic - a good Git reference

[erik quanstrom <quanstro@quanstro.net>]

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