Make Reed-Solomon data encoding for containers with enabled EC

[cthulhu-rider]

Is your feature request related to a problem? Please describe.

REP 1 containers make no sense in practice. Currently, one instance of each object is stored in such containers w/o redundancy. This resets the possibility of data recovery

Describe the solution you'd like

for containers with REP 1, enable RS encoding procedure described within #3419

Describe alternatives you've considered

keep REP 1 w/o redundancy and require explicit flag to enable EC in the container. Seems that there is no value in REP 1 now. So, this would only unnecessarily complicate the implementation

[roman-khimov]

This breaks existing REP 1 (consider AIO also). And we need some way to convey EC policy, so "EC X/Y" as an alternative to "REP X" makes much more sense to me. Leave REP as is. Think of "REP X IN ... EC Y/Z IN ..." policies as well.

[cthulhu-rider]

this breaks existing REP 1

that's not exactly true to me. Proposed EC adds redundancy only, data objects are compatible with current scheme. There will be no changes in terms of availability for old SNs. The only difference is placement and having both ECed and non-ECed chains in the same container. So, EC above REP 1 would become a pure feature from user POV

but, in general, i agree that EC is a completely different policy. At the same time, new policy format will raise new issues. The biggest one i see is:

old SNs only know to follow REP-policies. So, they should not be selected into EC containers. API version-based selections?

[roman-khimov]

old SNs only know to follow REP-policies. So, they should not be selected into EC containers. API version-based selections?

This can be a problem for any policy change. I'd rather have some global minimal API version available in settings, if it's lower than needed --- you don't have EC (or something else) and nodes with older API can't join the network. Then it can be moved forward as needed.

Practically though we don't have this problem now.

[cthulhu-rider]

Practically though we don't have this problem now.

then i suggest to design and implement EC policies with the precondition that all SNs in the network know how to process them

[roman-khimov]

REP X IN ... EC Y/Z IN ...

But then I'm not sure how to distribute complete/split objects properly. A single EC X/Y is not a problem, but there is conflict with REP Z that never existed in REP X REP Y scenarios.

[roman-khimov]

Although with header in every part policer can be smart enough to query different things in different machine sets.

[cthulhu-rider]

according to #3419 (comment), we need proper support of multi-level nesting of headers

[cthulhu-rider]

when limits (like max part/parity part num) will be stated, sync all verification funcs

#3557 (comment)