[PATCH 4 of 4] mmapindex: set default to 1MB

[Pulkit Goyal]

On Thu, Jan 3, 2019 at 2:37 PM Yuya Nishihara <yuya at tcha.org> wrote:

> On Wed, 2 Jan 2019 23:40:11 +0100, Boris FELD wrote:
> > On 04/12/2018 12:09, Yuya Nishihara wrote:
> > > On Sun, 02 Dec 2018 17:17:43 +0100, Boris Feld wrote:
> > >> # HG changeset patch
> > >> # User Boris Feld <boris.feld at octobus.net>
> > >> # Date 1542949784 -3600
> > >> #      Fri Nov 23 06:09:44 2018 +0100
> > >> # Node ID 9708243274585f9544c70925eb0b0fa0ec7aba4f
> > >> # Parent  0fff68dfbe48d87dce8b8736c0347ed5aa79030e
> > >> # EXP-Topic mmap
> > >> # Available At https://bitbucket.org/octobus/mercurial-devel/
> > >> #              hg pull https://bitbucket.org/octobus/mercurial-devel/
> -r 970824327458
> > >> mmapindex: set default to 1MB
> > > Can you check if strip/rollback properly copy the revlog before
> truncating it?
> > >
> > > If a mmapped revlog is truncated by another process, the mapped memory
> could be
> > > invalid. The worst case, the process would be killed by SIGBUS.
> >
> > Hum good catch, process reading a repository being stripped have always
> > been up for troubles. However, mmap makes it worse by raising a signal
> > instead of just having wonky seek. It also introduces new cases where
> > this can happen.
>
> mmap isn't worse because of SIGBUS, but because the index data can be
> updated
> after the index length is determined. Before, a single in-memory revlog
> index
> was at least consistent.
>
> > What shall we do here, I guess our best bet is to intercept these SIGBUS
> > when reading revlog index?
>
> I don't think it'll be easy to handle SIGBUS properly. And SIGBUS won't
> always
> be raised. Perhaps, the easiest solution is to copy the revlog index before
> strip/rollback.
>
> IIRC, the mmap implementation was highly experimental. I don't know if it's
> widely tested other than in FB where strip is never used.
>

We did use mmap implementation and strip both for some time and didn't
faced any issues except strip itself being an issue for slowdowns. However
our use was limited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190108/71c82b34/attachment.html>