From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Stefan Beller <sbeller@google.com>, Theodore Ts'o <tytso@mit.edu>,
git@vger.kernel.org, torvalds@linux-foundation.org
Subject: Re: [PATCH] Enable core.fsyncObjectFiles by default
Date: Tue, 23 Jun 2015 22:20:44 -0700 [thread overview]
Message-ID: <xmqqlhf9bs2b.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20150624033725.GA19321@peff.net> (Jeff King's message of "Tue, 23 Jun 2015 23:37:25 -0400")
Jeff King <peff@peff.net> writes:
> I had always assumed this was fine on ext4 with data=ordered (i.e.,
> either the rename and its pointed-to content will go through, or not; so
> you either get your update or the old state, but not a garbage or empty
> file). But it sounds from what Ted wrote in:
>
> http://article.gmane.org/gmane.linux.file-systems/97255
>
> that this may not be the case. If it's not, I think we should consider
> fsyncing ref writes.
That matches my understanding. IIRC, we do fsync (without a knob to
turn it off) packs, we do not fsync refs (as you described above),
the index, or working tree files (via write_entry()). Among these:
* If we are so paranoid that loss of new loose objects matter (as
opposed to "Heh, it is just the matter of 'git add' again") to
cause us to set core.fsyncObjectFiles, we should definitely fsync
ref writes. They are even more precious.
* The index is much less precious. In the worst case, you can 'git
reset' (no flags) and re-add from the working tree and nothing
unrecoverable is lost. I do not mind a knob to force us fsync,
but we may want it to be separate from core.fsyncObjectFiles.
* The working tree files? I am not sure. Again, recovery is just
to run "git diff" to notice what was eaten by the power failure
and then "git checkout $path" to restore from a known state,
so...
next prev parent reply other threads:[~2015-06-24 5:20 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-23 21:57 [PATCH] Enable core.fsyncObjectFiles by default Stefan Beller
2015-06-23 22:21 ` Junio C Hamano
2015-06-23 23:29 ` Theodore Ts'o
2015-06-24 5:32 ` Junio C Hamano
2015-06-24 14:30 ` Theodore Ts'o
2015-06-24 1:07 ` Duy Nguyen
2015-06-24 3:37 ` Jeff King
2015-06-24 5:20 ` Junio C Hamano [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-01-17 18:48 [PATCH] enable " Christoph Hellwig
2018-01-17 19:04 ` Junio C Hamano
2018-01-17 19:35 ` Christoph Hellwig
2018-01-17 20:05 ` Andreas Schwab
2018-01-17 19:37 ` Matthew Wilcox
2018-01-17 19:42 ` Christoph Hellwig
2018-01-17 21:44 ` Ævar Arnfjörð Bjarmason
2018-01-17 22:07 ` Linus Torvalds
2018-01-17 22:25 ` Linus Torvalds
2018-01-17 23:16 ` Ævar Arnfjörð Bjarmason
2018-01-17 23:42 ` Linus Torvalds
2018-01-17 23:52 ` Theodore Ts'o
2018-01-17 23:57 ` Linus Torvalds
2018-01-18 16:27 ` Christoph Hellwig
2018-01-19 19:08 ` Junio C Hamano
2018-01-20 22:14 ` Theodore Ts'o
2018-01-20 22:27 ` Junio C Hamano
2018-01-22 15:09 ` Ævar Arnfjörð Bjarmason
2018-01-22 18:09 ` Theodore Ts'o
2018-01-23 0:47 ` Jeff King
2018-01-23 5:45 ` Theodore Ts'o
2018-01-23 16:17 ` Jeff King
2018-01-23 0:25 ` Jeff King
2018-01-21 21:32 ` Chris Mason
2020-09-17 11:06 ` Ævar Arnfjörð Bjarmason
2020-09-17 14:14 ` Christoph Hellwig
2020-09-17 15:30 ` Junio C Hamano
2018-01-17 20:55 ` Jeff King
2018-01-17 21:10 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqlhf9bs2b.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=sbeller@google.com \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).