Allowing 1-stripe components in a FLR-EC file with --ec 1+2 is would be useful for regular filesystem usage to provide redundancy for a 2-OST failure. 1-stripe files are the most common use case for plain files, or the first component of a PFL file and would allow EC to provide redundancy for these files. While this would double the space usage for this component, the 1-stripe component is normally going to be only a fraction of the size of later striped components (typically about 5% of capacity), so tripling this usage would not significantly affect overall filesystem capacity (e.g. only 10% increase in total space usage, vs 25% increase for the larger files).

Unlike the --ec 1+1 case, there is at least one known issue that need to be addressed for this to work - if the EC component has 2 stripes in "RAID-0" configuration vs. the 1 stripe for the data component, then the EC stripe's size and block count would become larger.

This might be handled by creating the EC component as a "RAID1" layout pattern instead of "RAID0" and teaching the client how to handle this new layout type, which is not more incompatible than the EC layout pattern itself.

Another alternative would be to allow two separate EC parity mirrors on the same file, which has some other advantages:

• potentially allowing them to be resync'd independently (reducing "unprotected" time with 1/2 of the writes, though with double the reads)
• paving the way for "EC geometry rewriting" by allowing two different EC mirrors on a file at the same time (e.g. start with --ec 8+2, move to --ec 32+3 for very large cold files, if the data is striped across enough failure domains