cRAID5

The design of cRAID5 follows the RAID5 design framework, with the compression / decompression added in the data handling at the stripe level. The mapping between the logical stripe to the physical sub-stripe is done through a compression table look-up.

Some of the issues in the design of cRAID5 device are:

• For the cRAID5 device, the physical stripe also needs to be locked when the write on stripe is in progress, so that a write of some other unrelated logical stripe, residing in the same stripe due to compression, should not affect the parity information of the physical stripe.

• The compression algorithm to be used should not be memory and CPU time intensive. Compression and decompression occur inside the kernel so we cannot use any algorithm that uses floating point arithmetic (as the Linux kernel does not save floating point registers during mode switch).

• During a write to a compressed stripe, the new compressed length is usually different. This has to be properly handled by moving the physical stripe to some other suitable physical location, and then freeing the current physical location.

• No algorithm can promise good compression on all data. Sometimes there may not be any compression possible and such cases have to be handled properly. Presently, such stripes are stored with no compression with the stripe length in the compression table indicating a full stripe. This information is used during future reads/writes of the stripe. This can be extended (in future versions of TSS) to cover the cases where the resulting compression ratio is not worth the effort involved in compression and decompression (as specified by an user).