[TieredStorage] Make TieredStorage's Offset compatible with AccountsDB's offset

[yhchiang-sol]

Problem

AccountsDB currently assumes all offsets are multiple of 8, and this
applies to all AccountsFile API. However, TieredStorage uses its
IndexOffset that does not have this assumption.

Summary of Changes

This PR adds a conversion to make TieredStorage::IndexOffset
compatible with the AccountsDB offset inside the AccountsFile layer.

Test Plan

Tested by running a validator with TieredStorage manually enabled on mnb.
More accounts-db tests will be enabled with #334

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 19.04762% with 17 lines in your changes are missing coverage. Please review.

Project coverage is 81.9%. Comparing base (c867522) to head (2aa876c).
Report is 44 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master      #74   +/-   ##
=======================================
  Coverage    81.9%    81.9%           
=======================================
  Files         840      840           
  Lines      228098   228110   +12     
=======================================
+ Hits       186818   186858   +40     
+ Misses      41280    41252   -28     

[brooksprumo]

Hmm, we may need to make the index not divide by 8 automatically, and instead only do it for append vecs. I'm not sure how this will interact with forwards/backwards compatibility though.

Or maybe the StorageLocation gets a new variant? That may impact many other things too.

[brooksprumo]

@jeffwashington Adding you here as a reviewer. What do you think is a good way forward here, w.r.t. storing different offsets in the index?

[yhchiang-sol]

Hmm, we may need to make the index not divide by 8 automatically, and instead only do it for append vecs. I'm not sure how this will interact with forwards/backwards compatibility though.

Yep, I think this isn't the best way but offers an intermediate step to make tiered-storage runnable without changing the accounts-db + append-vec code path/logic. Ideally, we want to have accounts-db + append-vec logic untouched until we make tiered-storage default / proven to be stable.

[jeffwashington]

Hmm, we may need to make the index not divide by 8 automatically, and instead only do it for append vecs. I'm not sure how this will interact with forwards/backwards compatibility though.

Yep, I think this isn't the best way but offers an intermediate step to make tiered-storage runnable without changing the accounts-db + append-vec code path/logic. Ideally, we want to have accounts-db + append-vec logic untouched until we make tiered-storage default / proven to be stable.

this seems like it may be ok. I'm trying to figure out why the validators and ledger-tool were working without this change. I guess the indexes are *8 already somewhere else? I know I have hacked this in in a few places in my test branches. Maybe that's what I'm thinking of.

update: a version of this pr was in the prototype branch I was running:
4fbts-test-all

[jeffwashington]

this pr does appear consistent with the one I was running 4fbts-test-all. I think it is good to go.

[jeffwashington]

lgtm

[jeffwashington]

Hmm, we may need to make the index not divide by 8 automatically, and instead only do it for append vecs. I'm not sure how this will interact with forwards/backwards compatibility though.

Or maybe the StorageLocation gets a new variant? That may impact many other things too.

the index is using those extra bits for flags (like zero lamports), knowing that indexes were 8-byte aligned. This would be tricky to change. It does place an upper limit on offsets. This is not a problem at all for a 0,1,2 index. It is a limiting factor already for append vec offsets (where entries have a min size of 136 bytes or so). I thing this implementation is reasonable.

[brooksprumo]

the index is using those extra bits for flags (like zero lamports), knowing that indexes were 8-byte aligned. This would be tricky to change. It does place an upper limit on offsets. This is not a problem at all for a 0,1,2 index. It is a limiting factor already for append vec offsets (where entries have a min size of 136 bytes or so). I thing this implementation is reasonable.

The Hot Storage format has a max of 29 bits for the owner's offset. So this somewhat conservatively sets a maximum number of accounts per hot storage to 29 bits as well. So if we say there's a max of 29 bits for number of accounts, the hot storage will be compatible with the index's account info too, I believe.

[brooksprumo]

We can fixup/refactor the offsets later.