Re: [PATCH v4 2/4] core.fsync: introduce granular fsync control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 14, 2022 at 09:17:31AM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@xxxxxx> writes:
> 
> > To summarize my take: while the degree of durability may be something
> > that's up for discussions, I think that the current defaults for
> > atomicity are bad for users because they can and do lead to repository
> > corruption.
> 
> Good summary.
> 
> If the user cares about fsynching loose object files in the right
> way, we shouldn't leave loose ref files not following the safe
> safety level, regardless of how this new core.fsync knobs would look
> like.
> 
> I think we three are in agreement on that.

Is there anything I can specifically do to help out with this topic? We
have again hit data loss in production because we don't sync loose refs
to disk before renaming them into place, so I'd really love to sort out
this issue somehow so that I can revive my patch series which fixes the
known repository corruption [1].

Alternatively, can we maybe find a way forward with applying a version
of my patch series without first settling the bigger question of how we
want the overall design to look like? In my opinion repository
corruption is a severe bug that needs to be fixed, and it doesn't feel
sensible to block such a fix over a discussion that potentially will
take a long time to settle.

Patrick

[1]: http://public-inbox.org/git/cover.1636544377.git.ps@xxxxxx/

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux