On Sun, Nov 4, 2012 at 10:40 AM, Stefan Sperling <stsp_at_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.martin_at_wandisco.com>wrote:
> >
> > > Philip Martin <philip.martin_at_wandisco.com> writes:
> > >
> > > > Stefan Fuhrmann <stefan.fuhrmann_at_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
*
Received on 2012-11-05 14:59:36 CET