Junio C Hamano <gitster@xxxxxxxxx> writes:
> Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:
>
>> Junio C Hamano wrote:
>>>> $ ~/src/git
>>>> error: object file
>>>> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
>>>> error: object file
>>>> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
>>>> fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored
>>>> in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt
>>>
>>> So fsync() and close() thought that the filesystem stored this loose
>>> object safely, but it turns out that the data is not on disk.
>>
>> Where should I start digging if I want to fix this? Actually you just
>> need to tell me how to build reduced-case corruptions to test: I can
>> trace and figure out the rest.
>
> That is a trip in the kernel source, isn't it? I cannot be your
> guide there.
Not necessarily. AFAICT, Git won't fsync object files by default, but
does for pack files (to make sure the pack is written before unlinking
the object files being packed):
core.fsyncobjectfiles
This boolean will enable fsync() when writing object files.
This is a total waste of time and effort on a filesystem that
orders data writes properly, but can be useful for
filesystems that do not use journalling (traditional UNIX
filesystems) or that only journal metadata and not file
contents (OS X’s HFS+, or Linux ext3 with "data=writeback").
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html