From: Thomas Rast <trast@inf•ethz.ch>
To: "Kenneth Ölwing" <kenneth@olwing•se>
Cc: Git List <git@vger•kernel.org>
Subject: Re: Collective wisdom about repos on NFS accessed by concurrent clients (== corruption!?)
Date: Sat, 6 Apr 2013 10:11:33 +0200 [thread overview]
Message-ID: <871uaorscq.fsf@linux-k42r.v.cablecom.net> (raw)
In-Reply-To: <515EE38D.2000502@olwing.se> ("Kenneth \=\?utf-8\?Q\?\=C3\=96lwing\?\= \=\?utf-8\?Q\?\=22's\?\= message of "Fri, 05 Apr 2013 16:45:33 +0200")
Kenneth Ölwing <kenneth@olwing•se> writes:
> On 2013-04-05 15:42, Thomas Rast wrote:
>> Can you run the same tests under strace or similar, and gather the
>> relevant outputs? Otherwise it's probably very hard to say what is
>> going wrong. In particular we've had some reports on lustre that
>> boiled down to "impossible" returns from libc functions, not git
>> issues. It's hard to say without some evidence.
> Thomas, thanks for your reply.
>
> I'm assuming I should strace the git commands as they're issued? I'm
> already collecting regular stdout/err output in a log as I go. Is
> there any debugging things I can turn on to make the calls issue
> internal tracing of some sort?
I don't think there's any internal debugging that helps at this point.
Usually errors pointing to corruption are caused by a chain of syscalls
failing in some way, and the final error shows only the last one, so
strace() output is very interesting.
> The main issue I see is that I suspect it will generate so much data
> that it'll overflow my disk ;-).
Well, assuming you have some automated way of detecting when it fails,
you can just overwrite the same strace output file repeatedly; we're
only interested in the last one (or all the last ones if several gits
fail concurrently).
Fiddling with strace will unfortunately change the timings somewhat
(causing a bunch of extra context switches per syscall), but I hope that
you can still get it to reproduce.
--
Thomas Rast
trast@{inf,student}.ethz.ch
next prev parent reply other threads:[~2013-04-06 16:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-28 10:22 Collective wisdom about repos on NFS accessed by concurrent clients (== corruption!?) Kenneth Ölwing
2013-04-05 12:35 ` Kenneth Ölwing
2013-04-05 13:42 ` Thomas Rast
2013-04-05 14:45 ` Kenneth Ölwing
2013-04-06 8:11 ` Thomas Rast [this message]
2013-04-06 11:49 ` Jason Pyeron
2013-04-07 18:56 ` Kenneth Ölwing
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=871uaorscq.fsf@linux-k42r.v.cablecom.net \
--to=trast@inf$(echo .)ethz.ch \
--cc=git@vger$(echo .)kernel.org \
--cc=kenneth@olwing$(echo .)se \
/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