From: Eric Chamberland Date: Tue, 22 Jan 2013 21:31:09 GMT Subject: Re: GIT get corrupted on lustre Message-ID: <50FF051D.5090804@giref.ulaval.ca> In-Reply-To: <87r4lejpx8.fsf@pctrast.inf.ethz.ch> 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" 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). >