On Sun, Nov 4, 2012 at 10:40 AM, Stefan Sperling <s...@elego.de> wrote:
> On Wed, Oct 31, 2012 at 03:24:10PM +0100, Stefan Fuhrmann wrote: > > On Wed, Oct 31, 2012 at 2:54 PM, Philip Martin > > <philip.mar...@wandisco.com>wrote: > > > > > Philip Martin <philip.mar...@wandisco.com> writes: > > > > > > > Stefan Fuhrmann <stefan.fuhrm...@wandisco.com> writes: > > > > > > > >> Excellent analysis, Philip! With r1404112, we use "plain" > > > >> APR mmap code with almost no coding overhead. > > > >> The only downside is that we now have a temporary > > > >> file sitting in the db folder. > > > > > > > > Error handling needs attention: > > > > > > > > $ svnadmin create repo > > > > $ svnadmin dump repo > /dev/null > > > > $ chmod -rw repo/db/rev-prop-atomicsShm > > > > $ svnadmin dump repo > /dev/null > > > > Segmentation fault > > > > > > We are mmaping a 64k file, that's bigger than a disk block on lots of > > > filesystems so updates are not atomic. Do we have to consider > > > corruption: > > > > > > $ svnadmin create repo > > > $ dd if=/dev/urandom of=repo/db/rev-prop-atomicsShm bs=64k count=1 > > > $ svnadmin verify repo > > > Segmentation fault > > > $ svnadmin recover repo > > > Repository lock acquired. > > > Please wait; recovering the repository may take some time... > > > > > > Recovery completed. > > > The latest repos revision is 0. > > > $ svnadmin verify repo > > > Segmentation fault > > > > > > Perhaps recover should delete the file? > > > > > > > Done. Also, random data should no longer result in segfaults. > > I just came across something that reminded me of this thread. > It seems PostgreSQL is doing something quite similar to what we > want to do here: > > When the first PostgreSQL process attaches to the shared memory segment, > it > checks how many processes are attached. If the result is anything other > than > "one", it knows that there's another copy of PostgreSQL running which is > pointed at the same data directory, and it bails out. > http://rhaas.blogspot.nl/2012/06/absurd-shared-memory-limits.html > IIUIC, the problems they are trying to solve are: * have only one process open / manage a given data base * have SHM of arbitrary size Currently, we use named SHM to make the value of two 64 bit numbers per repo visible to all processes. Also, we don't have a master process that would channel access to a given repository. The "corruption" issue is only about how to behave if someone wrote random data to one of our repo files. That's being addressed now (don't crash, have a predictable behavior in most cases). If this works for postgres I wonder why it wouldn't work for us. > Is this something we cannot do because APR doesn't provide the > necessary abstractions? > The postgres code / approach may be helpful when we try to move the whole membuffer cache into a SHM segment. -- Stefan^2. -- Certified & Supported Apache Subversion Downloads: * http://www.wandisco.com/subversion/download *
