Migrations

Migrations result when a logical stripe changes type. A logical stripe changes from invalid to RAID5 on a write to it. After the migration is completed, the I/O is retried (this time in RAID5 fashion). If the request is a partial stripe write, another migration is triggered to make it RAID1. Thus a partial write to an invalid type stripe ultimately results in its migration to RAID1. A full stripe write to an invalid stripe only makes it a RAID5 stripe. An alternative strategy is to move the stripe directly from invalid to RAID1 on an update whether it is full stripe request or a partial one. We chose the 2-stage approach as we have no information whether the data will remain hot after this write. If it remains hot, the policy mechanisms will migrate it to RAID1. It also keeps the implementation simple and it is the right strategy for large I/Os.

RAID1 to RAID5 migration usually happens when a RAID1 stripe is victimized to give one of its physical stripes to a currently invalid logical stripe to make it RAID5 or to a RAID5 stripe to make it RAID1.

Our strategy for migrations to/from cRAID5 is similar. First migrate the needed stripe to RAID5 (leaving the other stripes in cRAID5 with certain parts invalid) and migrate to RAID1 as needed. RAID5 to cRAID5 migrations typically take place through policy mechanisms when the data becomes cold.

We use software LRU to maintain access frequencies of stripes.