From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <385c85ca703ac8d441c4227d1bb24643@u2.inri> <9c545c7fbde6ddecb82def2dc66194ed@lilly.quanstro.net> Date: Mon, 12 Oct 2015 19:54:47 +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=001a114023186fedde0521ec0673 Subject: Re: [9fans] off topic - a good Git reference Topicbox-Message-UUID: 7310383a-ead9-11e9-9d60-3106f5b1d025 --001a114023186fedde0521ec0673 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Has sense. Thanks Charles. =C3=81lvaro El 12/10/2015 19:03, "Charles Forsyth" escribi= =C3=B3: > > On 12 October 2015 at 17:49, =C3=81lvaro Jurado wr= ote: > >> what ensures sha key is in fs. > > > The reason many of us are a little sceptical about it being fsync as such > preventing the data appearing > is that if the git function that writes the key does a write or pwrite, > the key will be in the file system on Plan 9: there's no need for an fsyn= c > just to get it there. > In fact, in Linux there's no need for an fsync just to get it there: it > only matters in the case of a crash. > > If the file system fails or you reset the machine, the intention of the > fsync will be frustrated, but > it shouldn't affect normal operation where no file server crash occurs. > > As it happens, a wstat that changes nothing can be interpreted by a file > server to have a similar effect as fsync (see stat(5)). > --001a114023186fedde0521ec0673 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Has sense. Thanks Charles.

=C3=81lvaro

El 12/10/2015 19:03, "Charles Forsyth"= <charles.forsyth@gmail.com= > escribi=C3=B3:

On 12 October 2015 at 17:49, =C3=81lvaro Jurado <<= a href=3D"mailto:elbingmiss@gmail.com" target=3D"_blank">elbingmiss@gmail.c= om> wrote:
what ensures sha= key is in fs.

The reason many of us are a little sce= ptical about it being fsync as such preventing the data appearing
is that if the git function that writes the key does= a write or pwrite,
the key will be in the = file system on Plan 9: there's no need for an fsync just to get it ther= e.
In fact, in Linux there's no need fo= r an fsync just to get it there: it only matters in the case of a crash.

If the f= ile system fails or you reset the machine, the intention of the fsync will = be frustrated, but
it shouldn't affect = normal operation where no file server crash occurs.

As it happens, a wstat that c= hanges nothing can be interpreted by a file server to have a similar effect= as fsync (see stat(5)).
--001a114023186fedde0521ec0673--