All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Toon Claes <toon@iotcl.com>,
	Kristoffer Haugsbakk <code@khaugsbakk.name>
Subject: Re: [PATCH v2 4/5] reftable/writer: fix writing multi-level indices
Date: Tue, 6 Feb 2024 08:01:22 +0100	[thread overview]
Message-ID: <ZcHZQoqa74aUpbQl@tanuki> (raw)
In-Reply-To: <g5wshgzfv7x6om5zglsiv4bzsmhwcihwrqkmq4ebppiljqbreu@ml5eyr6zhkgu>

[-- Attachment #1: Type: text/plain, Size: 2120 bytes --]

On Mon, Feb 05, 2024 at 05:56:11PM -0600, jltobler wrote:
> On 24/02/01 08:52AM, Patrick Steinhardt wrote:
> > When finishing a section we will potentially write an index that makes
> > it more efficient to look up relevant blocks. The index records written
> > will encode, for each block of the indexed section, what the offset of
> > that block is as well as the last key of that block. Thus, the reader
> > would iterate through the index records to find the first key larger or
> > equal to the wanted key and then use the encoded offset to look up the
> > desired block.
> > 
> > When there are a lot of blocks to index though we may end up writing
> > multiple index blocks, too. To not require a linear search across all
> > index blocks we instead end up writing a multi-level index. Instead of
> > referring to the block we are after, an index record may point to
> > another index block. The reader will then access the highest-level index
> > and follow down the chain of index blocks until it hits the sought-after
> > block.
> > 
> > It has been observed though that it is impossible to seek ref records of
> > the last ref block when using a multi-level index. While the multi-level
> > index exists and looks fine for most of the part, the highest-level
> > index was missing an index record pointing to the last block of the next
> > index. Thus, every additional level made more refs become unseekable at
> > the end of the ref section.
> 
> Just to clarify, is only the highest-level index not recording the last
> block when multi-level indexes are being used? Or are the indexes at all
> levels leaving the last block unreachable?

Every level N+1 looses the last block of level N. So the latter.

Patrick

> > 
> > The root cause is that we are not flushing the last block of the current
> > level once done writing the level. Consequently, it wasn't recorded in
> > the blocks that need to be indexed by the next-higher level and thus we
> > forgot about it.
> > 
> > Fix this bug by flushing blocks after we have written all index records.
> 
>  -Justin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-02-06  7:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-26 10:31 [PATCH 0/5] reftable: fix writing multi-level indices Patrick Steinhardt
2024-01-26 10:31 ` [PATCH 1/5] reftable/reader: be more careful about errors in indexed seeks Patrick Steinhardt
2024-01-26 10:31 ` [PATCH 2/5] reftable/writer: use correct type to iterate through index entries Patrick Steinhardt
2024-01-26 10:31 ` [PATCH 3/5] reftable/writer: simplify writing index records Patrick Steinhardt
2024-01-31 13:44   ` Toon Claes
2024-02-01  8:39     ` Patrick Steinhardt
2024-01-31 15:55   ` Kristoffer Haugsbakk
2024-02-01  8:39     ` Patrick Steinhardt
2024-01-26 10:31 ` [PATCH 4/5] reftable/writer: fix writing multi-level indices Patrick Steinhardt
2024-01-26 10:31 ` [PATCH 5/5] reftable: document reading and writing indices Patrick Steinhardt
2024-01-26 16:26 ` [PATCH 0/5] reftable: fix writing multi-level indices Junio C Hamano
2024-02-01  7:51 ` [PATCH v2 " Patrick Steinhardt
2024-02-01  7:51   ` [PATCH v2 1/5] reftable/reader: be more careful about errors in indexed seeks Patrick Steinhardt
2024-02-01  7:52   ` [PATCH v2 2/5] reftable/writer: use correct type to iterate through index entries Patrick Steinhardt
2024-02-01  7:52   ` [PATCH v2 3/5] reftable/writer: simplify writing index records Patrick Steinhardt
2024-02-01  7:52   ` [PATCH v2 4/5] reftable/writer: fix writing multi-level indices Patrick Steinhardt
2024-02-05 23:56     ` jltobler
2024-02-06  7:01       ` Patrick Steinhardt [this message]
2024-02-01  7:52   ` [PATCH v2 5/5] reftable: document reading and writing indices Patrick Steinhardt
2024-02-06  1:43     ` jltobler
2024-02-06  7:04       ` Patrick Steinhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZcHZQoqa74aUpbQl@tanuki \
    --to=ps@pks.im \
    --cc=code@khaugsbakk.name \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=toon@iotcl.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.