Re: GIT get corrupted on lustre

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" [off-list ref] writes:

quoted

quoted

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().

quoted

quoted

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).