[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Idea for reducing disk IO on tagging operations

From: Dr. David Alan Gilbert
Subject: Re: Idea for reducing disk IO on tagging operations
Date: Wed, 23 Mar 2005 01:21:53 +0000
User-agent: Mutt/1.5.6+20040907i

* Mark D. Baushke (address@hidden) wrote:
> Hash: SHA1
> Paul Sander <address@hidden> writes:
> Actually, if you look closely, I believe that CVS will not do read-only
> RCS operations if a CVS write-lock exists for the directory. Of course,
> ViewCVS and CVSweb do it all the time as do many of the other add-ons.

I'm getting more worried about this one for 2 seperate reasons:
  1) There is talk of cvs -n for diff and the like which seems to
  suggest it ignores locks.
  2) I could do with a better under standing of the directory locks;
  pointers? I've read the top of lock.c but it still doesn't tell me
  enough; for example there seem to be multiple lock files used - but
  then surely the creation of them isn't atomic? Or is there one lock
  file used for both reading and writing?

> > There's also the interrupt issue:  Killing an update before it
> > completes leaves the RCS file corrupt.  You'd have to build in some
> > kind of crash recovery.  But RCS already has that by way of the comma
> > file, which can simply be deleted.  Other crash recovery algorithms
> > usually involve transaction logs that can be reversed and replayed, or
> > the creation of backup copies.  None of these are more efficient than
> > the existing RCS update protocol.
> Agreed. This is a very big deal.

Actually I'm becoming less worried by this; I'm failing to see any way
that a single system call write() to a block not crossing a block
boundary could partially fail; but I'm up for suggestions.


 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    | Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _________________________|_____   |_______/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]