1. 04 Sep, 2005 11 commits
  2. 30 Aug, 2005 3 commits
    • James Bottomley's avatar
      [SCSI] embryonic RAID class · 61a7afa2
      James Bottomley authored
      
      
      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: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      61a7afa2
    • James Bottomley's avatar
      [SCSI] attribute container final klist fixes · 2b7d6a8c
      James Bottomley authored
      Since the attribute container deletes from a klist while it's walking
      it, it is vulnerable to the problem (and fix) here:
      
      http://marc.theaimsgroup.com/?l=linux-scsi&m=112485448830217
      
      
      
      The attached fixes this (but won't compile without the above).
      
      It also fixes the logical reversal in the traversal loop which meant
      that we were never actually traversing the loop to hit this bug in the
      first place.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      2b7d6a8c
    • James Bottomley's avatar
      [SCSI] correct attribute_container list usage · 53c165e0
      James Bottomley authored
      
      
      One of the changes in the attribute_container code in the scsi-misc tree
      was to add a lock to protect the list of devices per container.  This,
      unfortunately, leads to potential scheduling while atomic problems if
      there's a sleep in the function called by a trigger.
      
      The correct solution is to use the kernel klist infrastructure instead
      which allows lockless traversal of a list.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      53c165e0
  3. 28 Aug, 2005 7 commits
  4. 15 Aug, 2005 3 commits
  5. 14 Aug, 2005 2 commits
  6. 13 Aug, 2005 1 commit
  7. 12 Aug, 2005 11 commits
  8. 09 Aug, 2005 1 commit
  9. 08 Aug, 2005 1 commit