ore: RAID5 read
authorBoaz Harrosh <bharrosh@panasas.com>
Wed, 12 Oct 2011 16:42:22 +0000 (18:42 +0200)
committerBoaz Harrosh <bharrosh@panasas.com>
Mon, 24 Oct 2011 23:55:36 +0000 (16:55 -0700)
commita1fec1dbbc8db974d2582e4040590cebe72171e4
tree9dcbe1933b7f40256f40393f3c86dbb16e8fb953
parent3e335672e018c06e007f85a5d54afd721fb3d6d5
ore: RAID5 read

This patch introduces the first stage of RAID5 support
mainly the skip-over-raid-units when reading. For
writes it inserts BLANK units, into where XOR blocks
should be calculated and written to.

It introduces the new "general raid maths", and the main
additional parameters and components needed for raid5.

Since at this stage it could corrupt future version that
actually do support raid5. The enablement of raid5
mounting and setting of parity-count > 0 is disabled. So
the raid5 code will never be used. Mounting of raid5 is
only enabled later once the basic XOR write is also in.
But if the patch "enable RAID5" is applied this code has
been tested to be able to properly read raid5 volumes
and is according to standard.

Also it has been tested that the new maths still properly
supports RAID0 and grouping code just as before.
(BTW: I have found more bugs in the pnfs-obj RAID math
 fixed here)

The ore.c file is getting too big, so new ore_raid.[hc]
files are added that will include the special raid stuff
that are not used in striping and mirrors. In future write
support these will get bigger.
When adding the ore_raid.c to Kbuild file I was forced to
rename ore.ko to libore.ko. Is it possible to keep source
file, say ore.c and module file ore.ko the same even if there
are multiple files inside ore.ko?

Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
fs/exofs/Kbuild
fs/exofs/ore.c
fs/exofs/ore_raid.c [new file with mode: 0644]
fs/exofs/ore_raid.h [new file with mode: 0644]
include/scsi/osd_ore.h