Somebody do something!

Goals

• implement 3-copy and 4-copy variant of the current RAID1 profile (that does 2 copies)
• configurable stripe length (currently fixed to 64k)
• implement raid5/6 logs to prevent write hole

Bonus

• switch to the more general naming scheme that better describes copies/stripes/parity than the traditional RAIDx
• research how much work is it to implement triple parity or more

Usecases

The raid5 or raid6 for metadata is going to be superseded by raid1 and raid1+3copies. The raid1+4copies is reserved for triple parity. The overall metadata size is typically orders of magnitude smaller than the data size so the overhead of the duplication should not be significant.

con:

• the simple copy of metadata will increase load of the devices where it's allocated, though the meatada can be relocated to other devices at idle times if necessary

pro:

• decreased load on all devices when a device is lost and needs to be resynced
• no need to recalculate parity and do full read-modify-write cycles
• parity can stay as-is, not checksummed
• the chances of loosing the metadata drive is ~2/N or ~3/N, so the rebuild does not necessarily have to be done

Write hole logs

The purpose of the log is to temporarily store incomplete stripe writes and the flush them to the regular stripes. On crash, the log is scanned and partial writes replayed.

The log has the same level of redundancy as the respective raid level and is stored as the 2copy or 3copy profile. The exact storage method of the log is to be determined. Possible ways:

• separate chunk type (data/metadata/system/raid5log/raid6log)
• internally hidden eg. as a special inode and accounted separately