From: "Sébastien Boisvert" <sebastien.boisvert@calculquebec•ca>
To: Thomas Rast <trast@student•ethz.ch>
Cc: Eric Chamberland <Eric.Chamberland@giref•ulaval.ca>,
"Brian J. Murrell" <brian@interlinx•bc.ca>,
git@vger•kernel.org, kusmabite@gmail•com, "Pyeron,
Jason J CTR (US)" <jason.j.pyeron.ctr@mail•mil>,
Maxime Boissonneault <maxime.boissonneault@calculquebec•ca>,
Philippe Vaucher <philippe.vaucher@gmail•com>
Subject: Re: GIT get corrupted on lustre
Date: Wed, 23 Jan 2013 09:45:51 -0500 [thread overview]
Message-ID: <50FFF79F.6080103@calculquebec.ca> (raw)
In-Reply-To: <878v7keuh3.fsf@pctrast.inf.ethz.ch>
On 01/22/2013 05:14 PM, Thomas Rast wrote:
> Eric Chamberland <Eric.Chamberland@giref•ulaval.ca> writes:
>
>> 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 thought you already established that simply disabling the progress
> display is a sufficient workaround? If that doesn't help, you can try
> patching out all use of SIGALRM within git.
>
In git (9591fcc6d66), I have found these SIGALRM signal handling:
builtin/log.c:268: sigaction(SIGALRM, &sa, NULL);
builtin/log.c:285: signal(SIGALRM, SIG_IGN);
compat/mingw.c:1590: mingw_raise(SIGALRM);
compat/mingw.c:1666: if (sig != SIGALRM)
compat/mingw.c:1668: error("sigaction only implemented for SIGALRM");
compat/mingw.c:1683: case SIGALRM:
compat/mingw.c:1702: case SIGALRM:
compat/mingw.c:1706: exit(128 + SIGALRM);
compat/mingw.c:1708: timer_fn(SIGALRM);
compat/mingw.h:42:#define SIGALRM 14
perl/Git/SVN.pm:2121: SIGALRM, SIGUSR1, SIGUSR2);
progress.c:56: sigaction(SIGALRM, &sa, NULL);
progress.c:68: signal(SIGALRM, SIG_IGN);
I suppose that compat/mingw.{h,c} and SVN.pm can be ignored as our patch to work
around this problem won't be pushed upstream because the real problem is not in git, right ?
If I understand correctly, some VFS system calls get interrupted by SIGALRM, but when
they resume (via SA_RESTART) they return EINTR. Thomas said that these failed calls may need to be retried,
but that open(O_CREAT|O_EXCL) is still tricky around this case.
progress.c SIGALRM code paths are for progress and therefore are required, right ?
builtin/log.c SIGALRM code paths are for early output, and the comments in the code say that
"If we can get the whole output in less than a tenth of a second, don't even bother doing the
early-output thing."
So where do I start for the patch ?
> Other than that I agree with Junio, from what we've seen so far, Lustre
> returns EINTR on all sorts of calls that simply aren't allowed to do so.
>
--
---
Spécialiste en granularité (1 journée / semaine)
Calcul Québec / Calcul Canada
Pavillon Adrien-Pouliot, Université Laval, Québec (Québec), Canada
next prev parent reply other threads:[~2013-01-23 14:47 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-24 14:08 GIT get corrupted on lustre Eric Chamberland
2012-12-24 14:48 ` Andreas Schwab
2012-12-24 15:11 ` Brian J. Murrell
2013-01-08 16:11 ` Eric Chamberland
2013-01-09 21:20 ` Eric Chamberland
2013-01-17 13:07 ` Eric Chamberland
2013-01-17 14:23 ` Philippe Vaucher
2013-01-17 16:30 ` Eric Chamberland
2013-01-17 16:40 ` Pyeron, Jason J CTR (US)
2013-01-17 16:41 ` Maxime Boissonneault
2013-01-17 17:17 ` Pyeron, Jason J CTR (US)
2013-01-18 17:50 ` Eric Chamberland
2013-01-21 13:29 ` Erik Faye-Lund
2013-01-21 16:11 ` Thomas Rast
2013-01-21 16:14 ` Maxime Boissonneault
2013-01-21 16:20 ` Thomas Rast
2013-01-21 18:54 ` Brian J. Murrell
2013-01-21 19:29 ` Thomas Rast
2013-01-22 21:31 ` Eric Chamberland
2013-01-22 22:03 ` Junio C Hamano
2013-01-22 22:14 ` Thomas Rast
2013-01-22 22:46 ` Eric Chamberland
2013-01-23 14:45 ` Sébastien Boisvert [this message]
2013-01-23 14:50 ` Sébastien Boisvert
2013-01-23 15:23 ` Erik Faye-Lund
2013-01-23 15:32 ` Thomas Rast
2013-01-23 15:32 ` Erik Faye-Lund
2013-01-23 15:44 ` Thomas Rast
2013-01-23 15:54 ` Erik Faye-Lund
2013-01-23 17:23 ` Jonathan Nieder
2013-01-23 18:34 ` Sébastien Boisvert
2013-02-04 13:58 ` Eric Chamberland
2013-01-21 17:07 ` Eric Chamberland
2013-01-21 18:28 ` Eric Chamberland
2012-12-25 1:11 ` Greg Troxel
2012-12-26 22:51 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50FFF79F.6080103@calculquebec.ca \
--to=sebastien.boisvert@calculquebec$(echo .)ca \
--cc=Eric.Chamberland@giref$(echo .)ulaval.ca \
--cc=brian@interlinx$(echo .)bc.ca \
--cc=git@vger$(echo .)kernel.org \
--cc=jason.j.pyeron.ctr@mail$(echo .)mil \
--cc=kusmabite@gmail$(echo .)com \
--cc=maxime.boissonneault@calculquebec$(echo .)ca \
--cc=philippe.vaucher@gmail$(echo .)com \
--cc=trast@student$(echo .)ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox