Mailing-List: contact cassandra-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of rff.rff@gmail.com designates
 74.125.78.150 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=XTEtVNOIHeBZIAANAWhJFXA20AV+iKcHkgXeDzNjDICZiShOmCxJAz6pSfzaePtqTD
         z1kt1ckU8RH9edvzjqMkheylhxEEYvep0Zh1rhPNvxuYs9iM39URzQFo+S89c8qGflNY
         +ednltUQwigocpJHOW8P4DQU1JD3NwFbNfIHA=
MIME-Version: 1.0
In-Reply-To: <1c6fcff1002260922m12fbcc1dg97048ec1bc727c39@mail.gmail.com>
References: <1c6fcff1002260922m12fbcc1dg97048ec1bc727c39@mail.gmail.com>
From: gabriele renzi <rff.rff@gmail.com>
Date: Fri, 26 Feb 2010 20:40:03 +0100
Message-ID: <828083e71002261140n3f54252p264b6288eb5d95f@mail.gmail.com>
Subject: Re: Commit log changes in 0.7
To: cassandra-dev@incubator.apache.org, gdusbabek@gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 26, 2010 at 6:22 PM, Gary Dusbabek <gdusbabek@gmail.com> wrote:
> The commit log currently has a header section whose size is constant,
> but is a function of the total number of defined column families.
> This isn't going to work with CASSANDRA-44 where CFs can be added or
> removed on the fly. =A0I see two options:
>
> 1. =A0hard code the size of the header to accommodate a maximum number
> of CFs. =A0I don't like this approach because it imposes a hard limit.
> 2. =A0move the header into its own file. =A0I don't like this because it
> adds complexity.
>
> Any better other ideas?

not a better idea, but just trying to understand: is there a reason
the fixed size "hard limit" can't be expanded when a new commit log is
created ?
E.g. start with N column families and leave space for M of them, if
one is added, a new commitlog is started with a larger header, and the
logic for cleaning up non-active logs becomes xoring the short header
against the equivalent portion of the new header.


I think there is some additional complexity, such as the need for a
prologue stating size/offsets, or if/how to handle deletions, but it
doesn't seem much.


--=20
blog en: http://www.riffraff.info
blog it: http://riffraff.blogsome.com