1. 15 12月, 2011 1 次提交
  2. 25 10月, 2011 3 次提交
    • B
      ore: RAID5 Write · 769ba8d9
      Boaz Harrosh 提交于
      This is finally the RAID5 Write support.
      
      The bigger part of this patch is not the XOR engine itself, But the
      read4write logic, which is a complete mini prepare_for_striping
      reading engine that can read scattered pages of a stripe into cache
      so it can be used for XOR calculation. That is, if the write was not
      stripe aligned.
      
      The main algorithm behind the XOR engine is the 2 dimensional array:
      	struct __stripe_pages_2d.
      A drawing might save 1000 words
      ---
      
      __stripe_pages_2d
             |
       n = pages_in_stripe_unit;
       w = group_width - parity;
             |                            pages array presented to the XOR lib
             |                                                |
             V                                                |
       __1_page_stripe[0].pages --> [c0][c1]..[cw][c_par] <---|
             |                                                |
       __1_page_stripe[1].pages --> [c0][c1]..[cw][c_par] <---
             |
      ...    |                         ...
             |
       __1_page_stripe[n].pages --> [c0][c1]..[cw][c_par]
                                     ^
                                     |
                 data added columns first then row
      
      ---
      The pages are put on this array columns first. .i.e:
      	p0-of-c0, p1-of-c0, ... pn-of-c0, p0-of-c1, ...
      So we are doing a corner turn of the pages.
      
      Note that pages will zigzag down and left. but are put sequentially
      in growing order. So when the time comes to XOR the stripe, only the
      beginning and end of the array need be checked. We scan the array
      and any NULL spot will be field by pages-to-be-read.
      
      The FS that wants to support RAID5 needs to supply an
      operations-vector that searches a given page in cache, and specifies
      if the page is uptodate or need reading. All these pages to be read
      are put on a slave ore_io_state and synchronously read. All the pages
      of a stripe are read in one IO, using the scatter gather mechanism.
      
      In write we constrain our IO to only be incomplete on a single
      stripe. Meaning either the complete IO is within a single stripe so
      we might have pages to read from both beginning  or end of the
      strip. Or we have some reading to do at beginning but end at strip
      boundary. The left over pages are pushed to the next IO by the API
      already established by previous work, where an IO offset/length
      combination presented to the ORE might get the length truncated and
      the user must re-submit the leftover pages. (Both exofs and NFS
      support this)
      
      But any ORE user should make it's best effort to align it's IO
      before hand and avoid complications. A cached ore_layout->stripe_size
      member can be used for that calculation. (NOTE: that ORE demands
      that stripe_size may not be bigger then 32bit)
      
      What else? Well read it and tell me.
      Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
      769ba8d9
    • B
      ore: RAID5 read · a1fec1db
      Boaz Harrosh 提交于
      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: NBoaz Harrosh <bharrosh@panasas.com>
      a1fec1db
    • B
      ore: Make ore_calc_stripe_info EXPORT_SYMBOL · 611d7a5d
      Boaz Harrosh 提交于
      ore_calc_stripe_info is needed by exofs::export.c
      for the layout calculations. Make it exportable
      Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
      611d7a5d
  3. 20 10月, 2011 3 次提交
  4. 16 10月, 2011 2 次提交
  5. 15 10月, 2011 4 次提交
    • B
      ore/exofs: Change ore_check_io API · 4b46c9f5
      Boaz Harrosh 提交于
      Current ore_check_io API receives a residual
      pointer, to report partial IO. But it is actually
      not used, because in a multiple devices IO there
      is never a linearity in the IO failure.
      
      On the other hand if every failing device is reported
      through a received callback measures can be taken to
      handle only failed devices. One at a time.
      
      This will also be needed by the objects-layout-driver
      for it's error reporting facility.
      
      Exofs is not currently using the new information and
      keeps the old behaviour of failing the complete IO in
      case of an error. (No partial completion)
      
      TODO: Use an ore_check_io callback to set_page_error only
      the failing pages. And re-dirty write pages.
      Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
      4b46c9f5
    • B
      ore/exofs: Define new ore_verify_layout · 5a51c0c7
      Boaz Harrosh 提交于
      All users of the ore will need to check if current code
      supports the given layout. For example RAID5/6 is not
      currently supported.
      
      So move all the checks from exofs/super.c to a new
      ore_verify_layout() to be used by ore users.
      
      Note that any new layout should be passed through the
      ore_verify_layout() because the ore engine will prepare
      and verify some internal members of ore_layout, and
      assumes it's called.
      Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
      5a51c0c7
    • B
      ore: Support for partial component table · 3bd98568
      Boaz Harrosh 提交于
      Users like the objlayout-driver would like to only pass
      a partial device table that covers the IO in question.
      For example exofs divides the file into raid-group-sized
      chunks and only serves group_width number of devices at
      a time.
      
      The partiality is communicated by setting
      ore_componets->first_dev and the array covers all logical
      devices from oc->first_dev upto (oc->first_dev + oc->numdevs)
      
      The ore_comp_dev() API receives a logical device index
      and returns the actual present device in the table.
      An out-of-range dev_index will BUG.
      
      Logical device index is the theoretical device index as if
      all the devices of a file are present. .i.e:
      	total_devs = group_width * mirror_p1 * group_count
      	0 <= dev_index < total_devs
      Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
      3bd98568
    • B
      ore: cleanup: Embed an ore_striping_info inside ore_io_state · 98260754
      Boaz Harrosh 提交于
      Now that each ore_io_state covers only a single raid group.
      A single striping_info math is needed. Embed one inside
      ore_io_state to cache the calculation results and eliminate
      an extra call.
      
      Also the outer _prepare_for_striping is removed since it does nothing.
      Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
      98260754
  6. 04 10月, 2011 1 次提交
    • B
      ore/exofs: Change the type of the devices array (API change) · d866d875
      Boaz Harrosh 提交于
      In the pNFS obj-LD the device table at the layout level needs
      to point to a device_cache node, where it is possible and likely
      that many layouts will point to the same device-nodes.
      
      In Exofs we have a more orderly structure where we have a single
      array of devices that repeats twice for a round-robin view of the
      device table
      
      This patch moves to a model that can be used by the pNFS obj-LD
      where struct ore_components holds an array of ore_dev-pointers.
      (ore_dev is newly defined and contains a struct osd_dev *od
       member)
      
      Each pointer in the array of pointers will point to a bigger
      user-defined dev_struct. That can be accessed by use of the
      container_of macro.
      
      In Exofs an __alloc_dev_table() function allocates the
      ore_dev-pointers array as well as an exofs_dev array, in one
      allocation and does the addresses dance to set everything pointing
      correctly. It still keeps the double allocation trick for the
      inodes round-robin view of the table.
      
      The device table is always allocated dynamically, also for the
      single device case. So it is unconditionally freed at umount.
      Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
      d866d875
  7. 03 10月, 2011 10 次提交
  8. 22 9月, 2011 1 次提交
    • D
      [SCSI] libsas: sgpio write support · 8ec6552f
      Dan Williams 提交于
      Add SFF-8485 v0.7 / SAS-1 smp-write-gpio register support to libsas.
      Defer SAS-2 support unless/until it defines an sgpio interface.
      
      Minimum implementation needed to get the lights blinking.
      try_test_sas_gpio_gp_bit() provides a common method to parse the
      incoming write data (raw bitstream), and the to_sas_gpio_gp_bit() helper
      routine can be used as a basis for the set/clear operations for the
      'read' implementation.  Host implementations parse as many bits
      (ODx.[012]) as are locally supported and report the number of registers
      successfully written.  If the submitted data overruns the internal
      number of registers available report the write as a success with the
      number of bytes remaining reported in ->resid_len.
      
      Example (assuming an active backplane) set the "identify" pattern for
      the first 21 devices:
      
      smp_write_gpio --count=2 --data=92,49,24,92,24,92,49,24 -t 4 --index=1 /dev/bsg/sas_hostX
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      8ec6552f
  9. 31 8月, 2011 2 次提交
  10. 29 8月, 2011 1 次提交
    • M
      [SCSI] scsi scan: don't fail scans when host is in recovery · 76e4e12f
      Mike Christie 提交于
      The problem is that if we are doing a scsi scan then the device goes
      into recovery then we will wait for the recovery to complete. It waits
      because scsi-ml will send inquiries or report luns and the queueing code
      will have been blocked due to the host not being ready. However, if we
      are in recovery and then a scan is started the scan will silently fail
      and some devices will not be added.
      
      It is easy to hit the problem where devices do not show up with
      FC where we are doing tests that disrupt the target controllers.
      When the controller is disruprted (reboot, or setting firmware, etc),
      and we cause the dev loss tmo to fire then devices will be removed
      Then when the problem has been fixed, the rport will be scanned and
      devices should be added back. But if we cause another disruption before
      scanning has started then devices will not get added back. If the problem
      is not started until the scan is started then the devices will be added
      back.
      
      This patch fixes that problem by not failing scans when the host
      is in recovery. We will let scsi-ml send the IO and let the queueing
      and scsi error handling deal with it like is done if we went into
      recovery while scanning.
      
      For recovery cases where the host is being torn down then with the
      patch we will still fail the scan since there is not point in scanning.
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      76e4e12f
  11. 27 8月, 2011 12 次提交