Next: Integrated Device
Up: Design of TSS
Previous: RAID1 and RAID5
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).
Next: Integrated Device
Up: Design of TSS
Previous: RAID1 and RAID5
2001-09-13