git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Meet Soni <meetsoni3017@gmail.com>
Cc: git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH v3 2/2] reftable: adapt writer code to propagate block_writer_add() errors
Date: Wed, 19 Mar 2025 14:18:15 +0100	[thread overview]
Message-ID: <Z9rEFzVkj2O76B7m@pks.im> (raw)
In-Reply-To: <CAPhwyn3rAaFZ0UYniJWUswAWyyPkDNgvKSvRpV6_H9v__txVog@mail.gmail.com>

On Thu, Mar 13, 2025 at 08:59:51PM +0530, Meet Soni wrote:
> On Wed, 12 Mar 2025 at 18:19, Patrick Steinhardt <ps@pks.im> wrote:
> >
> > > +     /*
> > > +      * The current block is full, so we need to flush and reinitialize the
> > > +      * writer to start writing the next block.
> > > +      */
> > >       arg->err = writer_flush_block(arg->w);
> > >       if (arg->err < 0)
> > >               goto done;
> >
> > But there is another case further down where we do `block_writer_add()`
> > and then re-try in case the write fails. This one is a bit more curious:
> > if the write fails, we don't create a new block -- after all we have
> > just created one. Instead, we reset the record's offset length to zero
> > before retrying.
> >
> > I _think_ that this is done because we know that when resetting the
> > offset we would write less data to the block, as can be seen in
> > `reftable_obj_record_encode()`. But I'm honestly not quite sure here as
> > I haven't yet done a deep dive into object records -- after all, we
> > don't even really use them in Git.
> >
> > In any case, I think that this callsite also needs adjustment and
> > warrants a comment. And if so, all changes to `write_object_record()`
> > should probably go into a separate commit, as well.
> >

Sorry for taking so long to respond.

> Regarding the callsite in write_object_record() where we reset the
> record's offset length to zero before retrying: my changes currently
> follow the same principle.
> 
>     - If block_writer_add() returns an error other than
>       REFTABLE_ENTRY_TOO_BIG_ERROR, we simply return.
> 
>     - For REFTABLE_ENTRY_TOO_BIG_ERROR, we flush the block and retry.
> 
>     - If that fails, we reset the record's offset length to zero and
>       then retry.

It's this last step that also needs to be adapted to check for
REFTABLE_ENTRY_TOO_BIG_ERROR, because the intent here is the exact same:
if writing the object record failed even in a completely new block then
we reset the object's offset and try a third time. But same as for the
first time, we don't check whether we get REFTABLE_ENTRY_TOO_BIG_ERROR
here and thus we might be failing and retrying even in unintended cases.

> I'm not sure what adjustments or additional comments you are referring to.
> Could you please clarify what changes you expect at this callsite?

So overall we'd add the check to both callsites, like in the below
patch.

Patrick

diff --git a/reftable/writer.c b/reftable/writer.c
index f3ab1035d61..63629e00a37 100644
--- a/reftable/writer.c
+++ b/reftable/writer.c
@@ -628,6 +628,8 @@ static void write_object_record(void *void_arg, void *key)
 	arg->err = block_writer_add(arg->w->block_writer, &rec);
 	if (arg->err == 0)
 		goto done;
+	if (arg->err != REFTABLE_ENTRY_TOO_BIG_ERROR)
+		goto done;
 
 	arg->err = writer_flush_block(arg->w);
 	if (arg->err < 0)
@@ -640,6 +642,8 @@ static void write_object_record(void *void_arg, void *key)
 	arg->err = block_writer_add(arg->w->block_writer, &rec);
 	if (arg->err == 0)
 		goto done;
+	if (arg->err != REFTABLE_ENTRY_TOO_BIG_ERROR)
+		goto done;
 
 	rec.u.obj.offset_len = 0;
 	arg->err = block_writer_add(arg->w->block_writer, &rec);


  reply	other threads:[~2025-03-19 13:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-06 12:13 [GSoC PATCH] reftable: return proper error code from block_writer_add() Meet Soni
2025-03-06 14:43 ` Patrick Steinhardt
2025-03-06 17:04 ` Junio C Hamano
2025-03-08 13:33 ` [GSoC PATCH v2] " Meet Soni
2025-03-12  8:23   ` Patrick Steinhardt
2025-03-12 12:11   ` [GSoC PATCH v3 0/2] reftable: return proper error codes from block_writer_add Meet Soni
2025-03-12 12:11     ` [PATCH v3 1/2] reftable: propagate specific error codes in block_writer_add() Meet Soni
2025-03-12 12:11     ` [PATCH v3 2/2] reftable: adapt writer code to propagate block_writer_add() errors Meet Soni
2025-03-12 12:49       ` Patrick Steinhardt
2025-03-13 15:29         ` Meet Soni
2025-03-19 13:18           ` Patrick Steinhardt [this message]
2025-03-19  7:59     ` [GSoC PATCH v4 0/3] reftable: return proper error codes from block_writer_add Meet Soni
2025-03-19  7:59       ` [PATCH v4 1/3] reftable: propagate specific error codes in block_writer_add() Meet Soni
2025-03-19  7:59       ` [PATCH v4 2/3] reftable: adapt writer_add_record() to propagate block_writer_add() errors Meet Soni
2025-03-19  7:59       ` [PATCH v4 3/3] reftable: adapt write_object_record() " Meet Soni
2025-03-19 15:29       ` [GSoC PATCH v5 0/3] reftable: return proper error codes from block_writer_add Meet Soni
2025-03-19 15:29         ` [GSoC PATCH v5 1/3] reftable: propagate specific error codes in block_writer_add() Meet Soni
2025-03-19 15:29         ` [GSoC PATCH v5 2/3] reftable: adapt writer_add_record() to propagate block_writer_add() errors Meet Soni
2025-03-19 15:29         ` [GSoC PATCH v5 3/3] reftable: adapt write_object_record() " Meet Soni
2025-03-19 15:48         ` [GSoC PATCH v5 0/3] reftable: return proper error codes from block_writer_add 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=Z9rEFzVkj2O76B7m@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=meetsoni3017@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).