Re: reftable [v6]: new ref storage format

From: Stefan Beller <sbeller@google.com>
Date: Aug 8, 2017, 23:52 UTC
Message-ID: <CAGZ79kbZiUDmp64FLYPOvT-Y4a8+YJF=fanYTB8Urxif9h6ZTg@mail.gmail.com>
In-Reply-To: <CAJo=hJvsdkrv6uELF0BHxqk4+as8-tr1bdYNHiQ3paTmn=2sRw@mail.gmail.com>

On Mon, Aug 7, 2017 at 11:30 AM, Shawn Pearce <spearce@spearce.org> wrote:

Show 14 quoted lines

> On Mon, Aug 7, 2017 at 11:27 AM, Stefan Beller <sbeller@google.com> wrote:
>> On Sun, Aug 6, 2017 at 6:47 PM, Shawn Pearce <spearce@spearce.org> wrote:
>>> 6th iteration of the reftable storage format.
>>>
>>> You can read a rendered version of this here:
>>> https://googlers.googlesource.com/sop/jgit/+/reftable/Documentation/technical/reftable.md
>>>
>>> The index may be organized into a multi-level index, where ...
>>> which may in turn point to either index blocks (3rd level) or ref blocks (leaf level).
>>
>> So we allow 3 levels at most?
>
> No, its just an example. Large ref sets with small block size need 4
> levels. Or more.

A malicious (or buggy) writer can produce indexes pointing to each other producing a circle. (Who would do that?)

A reader should - instead of segfaulting due to unbounded recursion or being stuck in an infinite loop - ignore the indexes in this case and fallback to the slow non-indexed behavior, i.e. while the file format allows for unbounded levels, a reader should not.