git/list[1] front-page[2] threads[3] people[4] search[5] about
 

RE: Collective wisdom about repos on NFS accessed by concurrent clients (== corruption!?)

From
Jason Pyeron <jpyeron@pdinc.us>
Date
Apr 6, 2013, 11:49 UTC
Message-ID
<CB4C1FB3EB914D079EE0534228DE372D@black>
In-Reply-To
<871uaorscq.fsf@linux-k42r.v.cablecom.net>
Show 34 quoted lines
> -----Original Message-----
> From: Thomas Rast
> Sent: Saturday, April 06, 2013 4:12
> 
> 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).

We use tmpwatch for this type of issue, especially with oracle traces. Set up a directory and tell tmpwatch to delete files older than X. This will keep the files at bay and when you detect a problem stop the clean up script.

> 
> 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.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc. http://www.pdinc.us -
- Principal Consultant              10 West 24th Street #100    -
- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
 
Previous: Thomas RastNext: Kenneth Ölwing
Message 6 of 7 in “Collective wisdom about repos on NFS accessed by concurrent clients (== corruption!?)”
  1. Kenneth ÖlwingMar 28, 2013
  2. Kenneth ÖlwingApr 5, 2013
  3. Thomas RastApr 5, 2013
  4. Kenneth ÖlwingApr 5, 2013
  5. Thomas RastApr 6, 2013
  6. Jason PyeronApr 6, 2013
  7. Kenneth ÖlwingApr 7, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.