Re: tree corrupted on disk quota full

[Andy Whitcroft <apw@shadowen.org>]

Andreas Ericsson wrote:
> Michael S. Tsirkin wrote:
>> I hit a quota limit on a disk my tree was on, but did not notice.
>> Doing git pull on a tree seems to have corrupted it.
>> Now I have:
>>
>> $ git-fsck-objects
>> error: 4d4d30be967d3284cbf59afd4fba6ab536e295f5: object not found
>> error: c03590b581d51d5fa43adbef9415e935d0229412: object not found
>> missing tree 10147d79b2418168d9433067b6439971bd4f1261
>> broken link from  commit 322a6c93ad86d2a151dd97a4c6b0e014a4893437
>>               to    tree 10147d79b2418168d9433067b6439971bd4f1261
>> dangling commit 322a6c93ad86d2a151dd97a4c6b0e014a4893437
>>
>> The tree can not be pulled into, or from.
>>
> 
> Can you do a "git rev-list" on the commit pointing to this tree? If so,
> you should be able to do "git reset HEAD~1" and re-do the fetch.
> 
> Otoh, this is curious. Aren't tree- and blob-objects written to disk
> before the commit object pointing to them? If not, how can we claim to
> support atomic commits? I imagined things were written in this order
> 
>     blob -> tree -> commit
> 
> seeing as the dependency chain goes the other way.
> 
> "git repair" could easily be cooked up by finding the first complete
> commit and resetting current HEAD and all branches pointing to it to
> that first complete commit. Issuing a fresh "fetch" after that should
> automagically fix everything for you.

Well we do have some dubious code which can fail in the face of short
writes when the disk is full.  Those I believe are now plugged following
my short i/o series which is in master as far as I know.

I wonder if we can cook up a test with a loop back mount on a tiny ramfs
that will fail in this way.

-apw