From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <385c85ca703ac8d441c4227d1bb24643@u2.inri> Date: Wed, 7 Oct 2015 23:23:22 +0200 Message-ID: From: =?UTF-8?Q?=C3=81lvaro_Jurado?= To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11407d1e39391205218a5b68 Subject: Re: [9fans] off topic - a good Git reference Topicbox-Message-UUID: 71471636-ead9-11e9-9d60-3106f5b1d025 --001a11407d1e39391205218a5b68 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. =C3=81lvaro El 07/10/2015 18:26, "Charles Forsyth" escribi= =C3=B3: > > On 7 October 2015 at 16:17, =C3=81lvaro Jurado wro= te: > >> because it has an strong dependency of fsync to freeze sha keys in fs >> during fetching. And that is just a dummy in Plan 9 ape > > > fsync causes any operating system buffers in the "buffer cache" to be > flushed to "disk" (not user-space buffers), so nothing should be needed > with plan 9, which is why fsync is a nop in APE. > --001a11407d1e39391205218a5b68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Yes, it has no sense in Plan 9, I know, thanks. I was talkin= g 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 questi= on saying that it's a matter of file server (I can't remember origi= nal question). And there are many debates around internet about fsync, with= fans an detractors.

In previous versions of git, there weren't fsyncs to fre= eze keys, but Linus wanted to change old git behaviour at one moment, 1.8 v= ersion I think. And after all, problem is still there in this case, there&#= 39;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.=

=C3=81lvaro

El 07/10/2015 18:26, "Charles Forsyth"= <charles.forsyth@gmail.com= > escribi=C3=B3:

On 7 October 2015 at 16:17, =C3=81lvaro Jurado <elbingmiss@gmail.co= m> wrote:
because it has a= n strong dependency of fsync to freeze sha keys in fs during fetching. And = that is just a dummy in Plan 9 ape

fsync causes any o= perating system buffers in the "buffer cache" to be flushed to &q= uot;disk" (not user-space buffers), so nothing should be needed with p= lan 9, which is why fsync is a nop in APE.
--001a11407d1e39391205218a5b68--