On Wed, Nov 10, 2021 at 09:23:04PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>
> Yes. I understand that we're not doing POSIX fsyncing().
>
> I'm asking about something else, i.e. with this not-like-POSIX-sync why
> it is that when you have a directory:
>
> A
>
> and files:
>
> A/{X,Y}
>
> That you'd write those two, and then proceed to do the "batch flush" by
> creating and fsync()-ing a:
>
> B/Z
>
> As opposed to either of:
>
> A/Z
>
> Or:
>
> Z
>
> I.e. why update .git/refs/* and create a flush file in .git/object/* and
> not .git/refs/* or .git/*?
>
> Maybe the answer is just that this is WIP code copied from your
> .git/objects/ fsync() implementation, or maybe it's more subtle and I'm
> missing something.
It looks I didn't really answer your actual question before. On the filesystems
which I'm familiar with at a code level (NTFS and ReFS on Windows), fsyncing a file
or dir anywhere on the filesystem should ensure that metadata operations completed
before the fsync starts are durable when the fsync returns. So which specific directory
we put the file in shouldn't matter as long as it's on the same filesystem as the other
files we're interested in.
>
> *nod*. See this if you haven't yet:
> https://lore.kernel.org/git/211110.86r1bogg27.gmgdl@xxxxxxxxxxxxxxxxxxx/T/#u
I'll respond on that thread with my opinion. Thanks for reviewing this and pushing
for a good holistic approach.
Thanks,
Neeraj
