11 Oct, 2011

2 commits


24 Jun, 2010

1 commit

  • Most array level changes leave the list of devices largely unchanged,
    possibly causing one at the end to become redundant.
    However conversions between RAID0 and RAID10 need to renumber
    all devices (except 0).

    This renumbering is currently being done in the ->run method when the
    new personality takes over. However this is too late as the common
    code in md.c might already have invalidated some of the devices if
    they had a ->raid_disk number that appeared to high.

    Moving it into the ->takeover method is too early as the array is
    still active at that time and wrong ->raid_disk numbers could cause
    confusion.

    So add a ->new_raid_disk field to mdk_rdev_s and use it to communicate
    the new raid_disk number.
    Now the common code knows exactly which devices need to be renumbered,
    and which can be invalidated, and can do it all at a convenient time
    when the array is suspend.
    It can also update some symlinks in sysfs which previously were not be
    updated correctly.

    Reported-by: Maciej Trela
    Signed-off-by: NeilBrown

    NeilBrown
     

18 May, 2010

1 commit


16 Jun, 2009

6 commits

  • Having a macro just to cast a void* isn't really helpful.
    I would must rather see that we are simply de-referencing ->private,
    than have to know what the macro does.

    So open code the macro everywhere and remove the pointless cast.

    Signed-off-by: NeilBrown

    NeilBrown
     
  • If we treat conf->devlist more like a 2 dimensional array,
    we can get the devlist for a particular zone simply by indexing
    that array, so we don't need to store the pointers to subarrays
    in strip_zone. This makes strip_zone smaller and so (hopefully)
    searches faster.

    Signed-of-by: NeilBrown

    NeilBrown
     
  • storing ->sectors is redundant as is can be computed from the
    difference z->zone_end - (z-1)->zone_end

    The one place where it is used, it is just as efficient to use
    a zone_end value instead.

    And removing it makes strip_zone smaller, so they array of these that
    is searched on every request has a better chance to say in cache.

    So discard the field and get the value from elsewhere.

    Signed-off-by: NeilBrown

    NeilBrown
     
  • The "sector_shift" and "spacing" fields of struct raid0_private_data
    were only used for the hash table lookups. So the removal of the
    hash table allows get rid of these fields as well which simplifies
    create_strip_zones() and raid0_run() quite a bit.

    Signed-off-by: Andre Noll
    Signed-off-by: NeilBrown

    Andre Noll
     
  • The raid0 hash table has become unused due to the changes in the
    previous patch. This patch removes the hash table allocation and
    setup code and kills the hash_table field of struct raid0_private_data.

    Signed-off-by: Andre Noll
    Signed-off-by: NeilBrown

    Andre Noll
     
  • The number of strip_zones of a raid0 array is bounded by the number of
    drives in the array and is in fact much smaller for typical setups. For
    example, any raid0 array containing identical disks will have only
    a single strip_zone.

    Therefore, the hash tables which are used for quickly finding the
    strip_zone that holds a particular sector are of questionable value
    and add quite a bit of unnecessary complexity.

    This patch replaces the hash table lookup by equivalent code which
    simply loops over all strip zones to find the zone that holds the
    given sector.

    In order to make this loop as fast as possible, the zone->start field
    of struct strip_zone has been renamed to zone_end, and it now stores
    the beginning of the next zone in sectors. This allows to save one
    addition in the loop.

    Subsequent cleanup patches will remove the hash table structure.

    Signed-off-by: Andre Noll
    Signed-off-by: NeilBrown

    Andre Noll
     

31 Mar, 2009

2 commits