Re: GIT get corrupted on lustre

[Eric Chamberland <Eric.Chamberland@giref.ulaval.ca>]

So, hum, do we have some sort of conclusion?

Shall it be a fix for git to get around that lustre "behavior"?

If something can be done in git it would be great: it is a *lot* easier 
to change git than the lustre filesystem software for a cluster in 
running in production mode... (words from cluster team) :-/

I hope this subject will not die in the list... :-/

Thanks,

Eric



On 01/21/2013 02:29 PM, Thomas Rast wrote:
> Please don't drop the Cc list!
>
> "Brian J. Murrell" <brian@interlinx.bc.ca> writes:
>
>>> What's odd is that while I cannot reproduce the original problem, there
>>> seems to be another issue/bug with utime():
>>
>> I wonder if this is related to http://jira.whamcloud.com/browse/LU-305.
>>   That was reported as fixed in Lustre 2.0.0 and 2.1.0 but I thought I
>> saw it on 2.1.1 and added a comment to the above ticket about that.
>
> Aha, that's a very interesting bug report.  My observations support
> yours: I managed to get EINTR during utime().
>
>>> In the absence of it, wouldn't we in theory have to write a simple
>>> loop-on-EINTR wrapper for *all* syscalls?
>>
>> IIUC, that's what SA_RESTART is all about.
>
> Yes, but there's precious little clear language on when SA_RESTART is
> supposed to act.  In all cases?
>
> The wording on
>
>    http://www.delorie.com/gnu/docs/glibc/libc_485.html
>    http://www.delorie.com/gnu/docs/glibc/libc_498.html
>
> leads me to believe that SA_RESTART is actually used on the glibc side
> of things, so that any glibc syscall wrapper not specifically equipped
> with the restarting behavior would return EINTR unmodified.  This might
> explain why utime() doesn't restart like it should (assuming we work on
> the theory that POSIX doesn't allow an EINTR from utime() to begin
> with).
>