Re: [HELP] Corrupted repository

From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: Jun 23, 2013, 17:48 UTC
Message-ID: <vpqwqpk4t26.fsf@anie.imag.fr>
In-Reply-To: <7vzjujl267.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 20 quoted lines

> Ramkumar Ramachandra <artagnon@gmail.com> 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/