Add EC Reed-Solomon GF(256) stripe pattern support

[jayapsrivastava]

What does this PR do / why do we need it?

Required for all PRs.

Related Issue(s)

Required when applicable.

Where should the reviewer(s) start reviewing this?

Only required for larger PRs when this may not be immediately obvious.

Are there any specific topics we should discuss before merging?

Not required.

What are the next steps after this PR?

Not required.

Checklist before merging:

Required for all PRs.

When creating a PR these are items to keep in mind that cannot be checked by GitHub actions:

• Documentation:
  • Does developer documentation (code comments, readme, etc.) need to be added or updated?
  • Does the user documentation need to be expanded or updated for this change?
• Testing:
  • Does this functionality require changing or adding new unit tests?
  • Does this functionality require changing or adding new integration tests?
• Git Hygiene:
  • Do commits adhere to Conventional Commits?
  • Is the commit history squashed down reasonably?

For more details refer to the Go coding standards and the pull request process.

[jayapsrivastava]

Hi @iamjoemccormick , I have the following question about the EC entry info implementation:

For beegfs entry info, both RAID0 and EC pattern information originates from the metadata service.
So for a mounted filesystem, the command uses GetEntryInfoV2. The client requests the information from meta and returns selected fields to beegfs-go through the ioctl structure.

The V2 ioctl currently returns the pattern type, chunk size, default target count, storage pool and target IDs. To show the EC data/parity composition and parity grouping, beegfs-go also needs numDataTargets and groupsParity.

So for this there are two possible approaches:

1. Keep the V2 ioctl structure unchanged and let beegfs-go request the complete EC pattern directly from meta.
2. Extend the V2 ioctl structure with these EC fields and keep the structures aligned in beegfs-core and beegfs-go.

Which approach should we use for EC entry info?

[iamjoemccormick]

Hi @iamjoemccormick , I have the following question about the EC entry info implementation:

For beegfs entry info, both RAID0 and EC pattern information originates from the metadata service. So for a mounted filesystem, the command uses GetEntryInfoV2. The client requests the information from meta and returns selected fields to beegfs-go through the ioctl structure.

The V2 ioctl currently returns the pattern type, chunk size, default target count, storage pool and target IDs. To show the EC data/parity composition and parity grouping, beegfs-go also needs numDataTargets and groupsParity.

So for this there are two possible approaches:

1. Keep the V2 ioctl structure unchanged and let beegfs-go request the complete EC pattern directly from meta.
2. Extend the V2 ioctl structure with these EC fields and keep the structures aligned in beegfs-core and beegfs-go.

Which approach should we use for EC entry info?

Hi @jayapsrivastava , we should add a GetEntryInfoV3 ioctl that also returns the new EC fields when applicable. We can't modify the V2 ioctl structure without creating compatibility issues. If we add a V3 ioctl then we can add another branch in getEntryAndOwnerFromPathViaIoctl() (e.g., if getEntryInfoV3Ioctl.ShouldAttempt()) and use the existing probecache mechanism that allows CTL to detect what ioctls are available on a particular client and be backwards compatible with any BeeGFS 8 client.