How does the combination of SPARSE_SUPER and FLEX_BG features impact the location of backup super blocks in EXT4?

Edit: I've posted an answer to the following below, but not accepted yet, in the hopes that someone will kindly provide me with a generic calculation for determining whether block group *n* will have a backup super block and descriptors at the start. I'm trying to understand the way in which EXT4 file systems are structured (i.e. the layout) on a block device, and in (manually) parsing my EXT4 file system (which has the

and

feature flags enabled), I'm finding that the actual layout (both from my parsing, and when summarised using

, and

) doesn't align with what I expect from my understanding of how those features work, and from the Kernel EXT4 documentation. It is my understanding that when the

feature is enabled, several block groups (16 in my case) will be treat as a single logical larger block group (flex group). As such, the first block group in the flex group will be used to store much of the metadata for the other block groups in the flex group (such as the block and inode bitmaps, inode table) - the remaining block groups can primarily be used for data (allowing more contiguous blocks for larger files, etc.). However, all block groups still contain backup copies of the super block and group descriptor table (and and reserved descriptor blocks), *as default*. It is my understanding that when the

feature flag is enabled, backup copies of the super block and group descriptors (and any reserved descriptor blocks) are **not** stored in every block group (as would be default), but, as per the EXT4 documentation, >are kept only in the groups whose group number is either 0 or a power of 3, 5, or 7 So, the expectation, is that these would be in block groups 0, 1, 8, 27, 32, 64, 128, 243.. etc. Or if the intention was to be *multiple of 3, 5, or 7*, the expectation would be backups in 0, 3, 5, 6, 7, 9, 10, 12, 14, 15, .. etc. However, in my case,

shows that backup copies of the super block are contained in block groups: 0, 1, 3, 5, 7, 9, 25, 27, 49, 81, 125, 243 This values align with the values I get when manually parsing the block device, so I know there's no bug in my code in this regard. As can be seen, there are some block groups aligning with being *powers of 3, 5, and 7*, All the block groups are also *multiples of* (1), 3, 5 and 7, but are not **all** multiples of these. So, what is the actual logic here, as it doesn't seem to completely align with the Kernel EXT4 documentation? How does the file system know whether a given block will have a backup super block (et al.) or not? Any advice, thoughts or knowledge appreciated.