A read to an invalid type stripe always succeeds. Backing physical stripe(s) are allocated on demand for writes making the stripe RAID5, and the operation is retried.
A write to a RAID1 stripe should update both the copies, whereas a read can be satisfied with either of the copies.
Reads and full stripe writes to a RAID5 stripe are handled in normal RAID5 fashion. During partial stripe writes, an attempt is made to migrate the whole stripe to RAID1 failing which the access is handled in RAID5 fashion.
Read in cRAID5 are handled by reading the stripe units of the compressed stripe. The data is uncompressed and the requested portion is copied to the target. Currently, no migrations are done as this will be left to policy modules (see below).
For write requests, the compressed data of the stripe is read, uncompressed and the old data overwritten by the new data. The data is then compressed and written in a new stripe or possibly in the original stripe itself. The latter is the best case when the number of physical blocks allocated to the new compressed stripe does not change. Otherwise, we need to find a new stripe that can accommodate this new compressed stripe and then release the storage in the old stripe. If compression is not good enough so that we need close to a full stripe itself for the write, the above read-modify-write cycle can be dispensed with in some cases if the write is for a full stripe. However, in all the above cases, no migrations are done, leaving the decisions to the policy modules.