On Tue, Jan 27, 2009 at 02:09:29PM +0100, Andreas Braathen wrote:
> futex seems to be a fast lock mechanism in Unix? Can I for instance try
> to turn of the locking to make
> it "less reliable" for a period to check this theory?
>
> >open("/afs/project/db/__db.001", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE,
> >0666) = -1 EEXIST (Fileexists)
> >open("/afs/project/db/__db.001", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE,
> >0666) = -1 EEXIST (Fileexists)
> >open("/afs/project/db/__db.001", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE,
> >0666) = -1 EEXIST (Fileexists)
> >open("/afs/project/db/__db.001", O_RDWR|O_LARGEFILE) = 4
> >fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> >fstat64(4, {st_mode=S_IFREG|0644, st_size=16384, ...}) = 0
> >close(4) = 0
> >open("/afsproject/db/__db.001", O_RDWR|O_LARGEFILE) = 4
> >fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> >mmap2(NULL, 16384, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0xb7cb7000
> >close(4) = 0
> >futex(0xb7cb7000, FUTEX_WAIT, 2, NULL
Maybe someone understands this more deeply than I do but I think you're
on the right track here. The fact that you say you haven't changed
anything else in your workflow definitely makes me want to dig into the
network-mounted filesystem as the source of the problems.
Turning off hard locks is a good starting point.
There's also a million other experiments you could try: sync the repo
onto a local disk and see if the problem persists. Make sure you can
access /afs/project/db/__db.001 with non-svn tools. Etc. etc.
good luck,
tyler
Received on 2009-01-27 21:07:12 CET