From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f67.google.com ([209.85.214.67]:45782 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753808AbeAQWHY (ORCPT ); Wed, 17 Jan 2018 17:07:24 -0500 MIME-Version: 1.0 In-Reply-To: <87h8rki2iu.fsf@evledraar.gmail.com> References: <20180117184828.31816-1-hch@lst.de> <87h8rki2iu.fsf@evledraar.gmail.com> From: Linus Torvalds Date: Wed, 17 Jan 2018 14:07:22 -0800 Message-ID: Subject: Re: [PATCH] enable core.fsyncObjectFiles by default To: =?UTF-8?B?w4Z2YXIgQXJuZmrDtnLDsCBCamFybWFzb24=?= Cc: Junio C Hamano , Christoph Hellwig , Git Mailing List , linux-fsdevel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Jan 17, 2018 at 1:44 PM, =C3=86var Arnfj=C3=B6r=C3=B0 Bjarmason wrote: > > I ran a small test myself on CentOS 7 (3.10) with ext4 data=3Dordered > on the tests I thought might do a lot of loose object writes: > > $ GIT_PERF_REPEAT_COUNT=3D10 GIT_PERF_LARGE_REPO=3D~/g/linux GIT_PE= RF_MAKE_OPTS=3D"NO_OPENSSL=3DY CFLAGS=3D-O3 -j56" ./run origin/master fsync= -on~ fsync-on p3400-rebase.sh p0007-write-cache.sh > [...] > Test fsy= nc-on~ fsync-on > -------------------------------------------------------------------= ------------------------------------ > 3400.2: rebase on top of a lot of unrelated changes 1.4= 5(1.30+0.17) 1.45(1.28+0.20) +0.0% > 3400.4: rebase a lot of unrelated changes without split-index 4.3= 4(3.71+0.66) 4.33(3.69+0.66) -0.2% > 3400.6: rebase a lot of unrelated changes with split-index 3.3= 8(2.94+0.47) 3.38(2.93+0.47) +0.0% > 0007.2: write_locked_index 3 times (3214 files) 0.0= 1(0.00+0.00) 0.01(0.00+0.00) +0.0% > > No impact. However I did my own test of running the test suite 10% > times with/without this patch, and it runs 9% slower: > > fsync-off: avg:21.59 21.50 21.50 21.52 21.53 21.54 21.57 21.59 21.61= 21.63 21.95 > fsync-on: avg:23.43 23.21 23.25 23.26 23.26 23.27 23.32 23.49 23.51= 23.83 23.88 That's not the thing you should check. Now re-do the test while another process writes to a totally unrelated a huge file (say, do a ISO file copy or something). That was the thing that several filesystems get completely and horribly wrong. Generally _particularly_ the logging filesystems that don't even need the fsync, because they use a single log for everything (so fsync serializes all the writes, not just the writes to the one file it's fsync'ing). The original git design was very much to write each object file without any syncing, because they don't matter since a new object file - by definition - isn't really reachable. Then sync before writing the index file or a new ref. But things have changed, I'm not arguing that the code shouldn't be made safe by default. I personally refuse to use rotating media on my machines anyway, largely exactly because of the fsync() issue (things like "firefox" started doing fsync on the mysql database for stupid things, and you'd get huge pauses). But I do think your benchmark is wrong. The case where only git does something is not interesting or relevant. It really is "git does something _and_ somebody else writes something entirely unrelated at the same time" that matters. Linus