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 18:00:11 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11c1b90e34c4b10521eb43ef Subject: Re: [9fans] off topic - a good Git reference Topicbox-Message-UUID: 7302baa2-ead9-11e9-9d60-3106f5b1d025 --001a11c1b90e34c4b10521eb43ef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12 October 2015 at 17:49, =C3=81lvaro Jurado wrot= e: > 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 fsync 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)). --001a11c1b90e34c4b10521eb43ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

--001a11c1b90e34c4b10521eb43ef--