Return-Path: X-Original-To: apmail-subversion-dev-archive@minotaur.apache.org Delivered-To: apmail-subversion-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 51B061144A for ; Tue, 17 Jun 2014 20:20:39 +0000 (UTC) Received: (qmail 31018 invoked by uid 500); 17 Jun 2014 20:20:39 -0000 Delivered-To: apmail-subversion-dev-archive@subversion.apache.org Received: (qmail 30964 invoked by uid 500); 17 Jun 2014 20:20:39 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 30954 invoked by uid 99); 17 Jun 2014 20:20:38 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Jun 2014 20:20:38 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of stefan.fuhrmann@wandisco.com designates 209.85.213.179 as permitted sender) Received: from [209.85.213.179] (HELO mail-ig0-f179.google.com) (209.85.213.179) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Jun 2014 20:20:34 +0000 Received: by mail-ig0-f179.google.com with SMTP id r2so22114igi.0 for ; Tue, 17 Jun 2014 13:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wandisco.com; s=gapps; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SX4lAXlVakgWwzrTpT1wRMe1LKCqwBK4fDAvfpxsDFc=; b=QAUVjVLuUXadMzEE17d8HFc/4QwGGJEI5ljXdbww8siUpGU3jqJAmS1NfMuKo1W+JE Mqo8bUobXEH4fJvJdITgjVWLeOHKof0Y5hJwdApjgkSEbSvIBRq5K0B7SQH6+RjKkmus O14Si9z8AtVNVwN3HRu46YqMMTOCt3dVF7fgw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SX4lAXlVakgWwzrTpT1wRMe1LKCqwBK4fDAvfpxsDFc=; b=R5qQrY/KoPwxElYr8hGUtWkbscpTjDzf052jek0TeLxFccrbs67zWijqbXYRu9AyLa olgIunKQh8dXc32kkDEO3UCjXipliyD9RFwzzsFGy9ZiDOAyW7+zMoH9BwvkmZtGI/fl viwvWhrvbPOdRoEZxpUPHlN+iEUavTwAaBemIilvWes3guwrGpSBm6/mSSIfL9PnRCev EfUYsMufDetEcakhJs9GE0qEmQFjoOXi/3Qx/FwsHYPgpsrZeMCFVqJPDFtwSVrDwqiV 9CTcr8PrXvwBmzJSFRpIDRCym8XYDS61b2T4NH4NYgNddh1VbKHoYrmjS1DWh/hiEhnN BWaA== X-Gm-Message-State: ALoCoQk62qp9TuoiX9Ooq4OlBneU2x5ZQCQAixrOtsZi/Ry/4x8mWh5jQZ92iMFmWlwVSRuPmpt7 MIME-Version: 1.0 X-Received: by 10.43.2.200 with SMTP id nv8mr3112724icb.92.1403036413607; Tue, 17 Jun 2014 13:20:13 -0700 (PDT) Received: by 10.50.231.138 with HTTP; Tue, 17 Jun 2014 13:20:13 -0700 (PDT) In-Reply-To: <878uow62tt.fsf@ntlworld.com> References: <20140616135316.GB10450@ted.stsp.name> <20140616153354.GC10450@ted.stsp.name> <878uow62tt.fsf@ntlworld.com> Date: Tue, 17 Jun 2014 22:20:13 +0200 Message-ID: Subject: Re: enable packing by default From: Stefan Fuhrmann To: Philip Martin Cc: Subversion Development Content-Type: multipart/alternative; boundary=bcaec50fe2dd0a562404fc0ddfe3 X-Virus-Checked: Checked by ClamAV on apache.org --bcaec50fe2dd0a562404fc0ddfe3 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 16, 2014 at 10:01 PM, Philip Martin wrote: > Stefan Sperling writes: > > > On Mon, Jun 16, 2014 at 03:53:16PM +0200, Stefan Sperling wrote: > >> Stefan2 pointed out that format 7 is less efficient if packing is > disabled. > >> So to fully benefit from format 7 in the default configuration, users > must > >> currently run 'svnadmin pack' or edit fsfs.conf to enable packing after > commit. > >> Since format 7 adds locking support to pack, so it should be safe to > trigger > >> packing at any time. > >> > >> It looks like it makes sense to enable packing after commit by default > >> for format 7 repositories. Any objections? > > > > And here's a more complete patch, fixing test fallout. > > > > [[[ > > Enable packing by default in format 7 FSFS repositories. > > > > * subversion/libsvn_fs_fs/fs.h > > (CONFIG_SECTION_DEBUG): Remove. > > (CONFIG_SECTION_PACKED_REVS): New configuration section > "packed-revisions", > > which contains options controlling revision packing behaviour. > (Perhaps this > > should be called "packing" and merged with the "packed-revprops" > section in > > a backwards-compatible way.) > > > > * subversion/libsvn_fs_fs/fs_fs.c > > (read_config): If the file format supports the pack lock, default to > > pack-after-commit. > > One thing to consider is the behaviour of a large, unpacked, repository > when upgraded from format 6 to format 7: if we pack by default the first > commit after the upgrade will pack the whole repository which could take > a long time and the committing client may well timeout. The admin could > avoid this by running pack manually after the upgrade, or should upgrade > invoke pack automatically (perhaps controlled by the same config flag)? > I think, upgrade should automatically pack by default - with an option to override that via fsfs.conf. We gain nothing by deferring the pack until the next full shard. Packing itself is save in the sense that it can be (non- gracefully) interrupted and restarted at any time with no long-term ill effects. Partially written pack files will simply linger around until they get cleaned up by the next pack run. -- Stefan^2. --bcaec50fe2dd0a562404fc0ddfe3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 16, 2014 at 10:01 PM, Philip Martin <philip.martin@wand= isco.com> wrote:
Stefan Sperling <stsp@elego.de> writes:

> On Mon, Jun 16, 2014 at 03:53:16PM +0200, Stefan Sperling wrote:
>> Stefan2 pointed out that format 7 is less efficient if packing is = disabled.
>> So to fully benefit from format 7 in the default configuration, us= ers must
>> currently run 'svnadmin pack' or edit fsfs.conf to enable = packing after commit.
>> Since format 7 adds locking support to pack, so it should be safe = to trigger
>> packing at any time.
>>
>> It looks like it makes sense to enable packing after commit by def= ault
>> for format 7 repositories. Any objections?
>
> And here's a more complete patch, fixing test fallout.
>
> [[[
> Enable packing by default in format 7 FSFS repositories.
>
> * subversion/libsvn_fs_fs/fs.h
> =C2=A0 (CONFIG_SECTION_DEBUG): Remove.
> =C2=A0 (CONFIG_SECTION_PACKED_REVS): New configuration section "p= acked-revisions",
> =C2=A0 =C2=A0which contains options controlling revision packing behav= iour. (Perhaps this
> =C2=A0 =C2=A0should be called "packing" and merged with the = "packed-revprops" section in
> =C2=A0 =C2=A0a backwards-compatible way.)
>
> * subversion/libsvn_fs_fs/fs_fs.c
> =C2=A0 (read_config): If the file format supports the pack lock, defau= lt to
> =C2=A0 =C2=A0pack-after-commit.

One thing to consider is the behaviour of a large, unpacked, reposito= ry
when upgraded from format 6 to format 7: if we pack by default the first commit after the upgrade will pack the whole repository which could take a long time and the committing client may well timeout. =C2=A0The admin cou= ld
avoid this by running pack manually after the upgrade, or should upgrade invoke pack automatically (perhaps controlled by the same config flag)?
=

I think, upgrade should automatically pack= by default -
with an option to override that via fsfs.conf. = We gain
nothing by deferring the pack until the next full shard.

= Packing itself is save in the sense that it can be (non-
gracefully) int= errupted and restarted at any time with
no long-term ill effects. Partia= lly written pack files will
simply linger around until they get cleaned up by the
next pack run.
=
-- Stefan^2.

--bcaec50fe2dd0a562404fc0ddfe3--