summaryrefslogtreecommitdiff
path: root/include/linux/raid_class.h
AgeCommit message (Collapse)AuthorFilesLines
2010-02-08[SCSI] mpt2sas: Added raid transport supportKashyap, Desai1-0/+1
Adding support for raid transport layer. This will provide sysfs attributes containing raid level, state, and resync rate. MPT2SAS module will select RAID_ATTRS. Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com> Reviewed-by: Eric Moore <eric.moore@lsi.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2008-04-19SCSI: convert struct class_device to struct deviceTony Jones1-6/+6
It's big, but there doesn't seem to be a way to split it up smaller... Signed-off-by: Tony Jones <tonyj@suse.de> Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Cc: Roland Dreier <rolandd@cisco.com> Cc: Sean Hefty <sean.hefty@intel.com> Cc: Hal Rosenstock <hal.rosenstock@gmail.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-04[SCSI] raid class: handle component-add errorsJeff Garzik1-2/+3
Signed-off-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-01-12[SCSI] raid_class.c - adding RAID10 and RAID10 definesMoore, Eric1-0/+2
Adding defines for RAID10 and RAID50 levels, in preparation of adding RAID Transport support in the mpt fusion drivers. (BTW: IME is RAID10, and IM is RAID1). Signed-off-by: Eric Moore <Eric.Moore@lsil.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-11-06[SCSI] raid class updateJames Bottomley1-6/+26
- Update raid class to use nested classes for raid components (this will allow us to move to a component control model now) - Make the raid level an enumeration rather than and int. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-08-30[SCSI] embryonic RAID classJames Bottomley1-0/+59
The idea behind a RAID class is to provide a uniform interface to all RAID subsystems (both hardware and software) in the kernel. To do that, I've made this class a transport class that's entirely subsystem independent (although the matching routines have to match per subsystem, as you'll see looking at the code). I put it in the scsi subdirectory purely because I needed somewhere to play with it, but it's not a scsi specific module. I used a fusion raid card as the test bed for this; with that kind of card, this is the type of class output you get: jejb@titanic> ls -l /sys/class/raid_devices/20\:0\:0\:0/ total 0 lrwxrwxrwx 1 root root 0 Aug 16 17:21 component-0 -> ../../../devices/pci0000:80/0000:80:04.0/host20/target20:1:0/20:1:0:0/ lrwxrwxrwx 1 root root 0 Aug 16 17:21 component-1 -> ../../../devices/pci0000:80/0000:80:04.0/host20/target20:1:1/20:1:1:0/ lrwxrwxrwx 1 root root 0 Aug 16 17:21 device -> ../../../devices/pci0000:80/0000:80:04.0/host20/target20:0:0/20:0:0:0/ -r--r--r-- 1 root root 16384 Aug 16 17:21 level -r--r--r-- 1 root root 16384 Aug 16 17:21 resync -r--r--r-- 1 root root 16384 Aug 16 17:21 state So it's really simple: for a SCSI device representing a hardware raid, it shows the raid level, the array state, the resync % complete (if the state is resyncing) and the underlying components of the RAID (these are exposed in fusion on the virtual channel 1). As you can see, this type of information can be exported by almost anything, including software raid. The more difficult trick, of course, is going to be getting it to perform configuration type actions with writable attributes. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>