Re: [PATCH v2 13/19] midx: teach `midx_preferred_pack()` about incremental MIDXs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 17, 2024 at 05:12:35PM -0400, Taylor Blau wrote:

> The function `midx_preferred_pack()` is used to determine the identity
> of the preferred pack, which is the identity of a unique pack within
> the MIDX which is used as a tie-breaker when selecting from which pack
> to represent an object that appears in multiple packs within the MIDX.
> 
> Historically we have said that the MIDX's preferred pack has the unique
> property that all objects from that pack are represented in the MIDX.
> But that isn't quite true: a more precise statement would be that all
> objects from that pack *which appear in the MIDX* are selected from that
> pack.
> 
> This helps us extend the concept of preferred packs across a MIDX chain,
> where some object(s) in the preferred pack may appear in other packs
> in an earlier MIDX layer, in which case those object(s) will not appear
> in a subsequent MIDX layer from either the preferred pack or any other
> pack.

OK, that matches my intuition for how the preferred concept should
exist. I'm not quite clear on how that will affect the code, though.

> diff --git a/midx.c b/midx.c
> index 0fa8febb9d..d2dbea41e4 100644
> --- a/midx.c
> +++ b/midx.c
> @@ -500,13 +500,16 @@ int midx_contains_pack(struct multi_pack_index *m, const char *idx_or_pack_name)
>  int midx_preferred_pack(struct multi_pack_index *m, uint32_t *pack_int_id)
>  {
>  	if (m->preferred_pack_idx == -1) {
> +		uint32_t midx_pos;
>  		if (load_midx_revindex(m) < 0) {
>  			m->preferred_pack_idx = -2;
>  			return -1;
>  		}
>  
> -		m->preferred_pack_idx =
> -			nth_midxed_pack_int_id(m, pack_pos_to_midx(m, 0));
> +		midx_pos = pack_pos_to_midx(m, m->num_objects_in_base);
> +
> +		m->preferred_pack_idx = nth_midxed_pack_int_id(m, midx_pos);
> +

OK, so rather than looking for the pack of object 0, we're looking for
the first one in _this_ layer, since the position is global within the
midx. That makes some sense, but is pack_pos_to_midx() ready for that?
It looks like it just looks at m->revindex_data. Are we going to be
generating a revindex for the whole chain? I'd think that each layer
would have its own revindex (and any trickiness would happen at the
generation stage, making sure we don't insert objects that are already
mentioned in earlier layers).

-Peff




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux