18 Jun, 2009

3 commits

  • If the superblock of a component device indicates the presence of a
    bitmap but the corresponding raid personality does not support bitmaps
    (raid0, linear, multipath, faulty), then something is seriously wrong
    and we'd better refuse to run such an array.

    Currently, this check is performed while the superblocks are examined,
    i.e. before entering personality code. Therefore the generic md layer
    must know which raid levels support bitmaps and which do not.

    This patch avoids this layer violation without adding identical code
    to various personalities. This is accomplished by introducing a new
    public function to md.c, md_check_no_bitmap(), which replaces the
    hard-coded checks in the superblock loading functions.

    A call to md_check_no_bitmap() is added to the ->run method of each
    personality which does not support bitmaps and assembly is aborted
    if at least one component device contains a bitmap.

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

    Andre Noll
     
  • The difference between these two methods is artificial.
    Both check that a pending reshape is valid, and perform any
    aspect of it that can be done immediately.
    'reconfig' handles chunk size and layout.
    'check_reshape' handles raid_disks.

    So make them just one method.

    Signed-off-by: NeilBrown

    NeilBrown
     
  • Passing the new layout and chunksize as args is not necessary as
    the mddev has fields for new_check and new_layout.

    This is preparation for combining the check_reshape and reconfig
    methods

    Signed-off-by: NeilBrown

    NeilBrown
     

31 Mar, 2009

5 commits

  • Get personalities out of the business of directly modifying
    ->array_sectors. Lays groundwork to introduce policy on when
    ->array_sectors can be modified.

    Reviewed-by: Andre Noll
    Signed-off-by: Dan Williams

    Dan Williams
     
  • In preparation for giving userspace control over ->array_sectors we need
    to be able to retrieve the 'default' size, and the 'anticipated' size
    when a reshape is requested. For personalities that do not reshape emit
    a warning if anything but the default size is requested.

    In the raid5 case we need to update ->previous_raid_disks to make the
    new 'default' size available.

    Reviewed-by: Andre Noll
    Signed-off-by: Dan Williams

    Dan Williams
     
  • This patch renames the "size" field of struct mddev_s to "dev_sectors"
    and stores the number of 512-byte sectors instead of the number of
    1K-blocks in it.

    All users of that field, including raid levels 1,4-6,10, are adjusted
    accordingly. This simplifies the code a bit because it allows to get
    rid of a couple of divisions/multiplications by two.

    In order to make checkpatch happy, some minor coding style issues
    have also been addressed. In particular, size_store() now uses
    strict_strtoull() instead of simple_strtoull().

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

    Andre Noll
     
  • It really is nicer to keep related code together..

    Signed-off-by: NeilBrown

    NeilBrown
     
  • This makes the includes more explicit, and is preparation for moving
    md_k.h to drivers/md/md.h

    Remove include/raid/md.h as its only remaining use was to #include
    other files.

    Signed-off-by: NeilBrown

    NeilBrown
     

09 Jan, 2009

1 commit

  • The rdev_for_each macro defined in is identical to
    list_for_each_entry_safe, from , it should be defined to
    use list_for_each_entry_safe, instead of reinventing the wheel.

    But some calls to each_entry_safe don't really need a safe version,
    just a direct list_for_each_entry is enough, this could save a temp
    variable (tmp) in every function that used rdev_for_each.

    In this patch, most rdev_for_each loops are replaced by list_for_each_entry,
    totally save many tmp vars; and only in the other situations that will call
    list_del to delete an entry, the safe version is used.

    Signed-off-by: Cheng Renquan
    Signed-off-by: NeilBrown

    Cheng Renquan
     

16 Oct, 2008

1 commit


21 Jul, 2008

1 commit


07 Feb, 2008

1 commit


10 Oct, 2007

1 commit

  • As bi_end_io is only called once when the reqeust is complete,
    the 'size' argument is now redundant. Remove it.

    Now there is no need for bio_endio to subtract the size completed
    from bi_size. So don't do that either.

    While we are at it, change bi_end_io to return void.

    Signed-off-by: Neil Brown
    Signed-off-by: Jens Axboe

    NeilBrown
     

24 Jul, 2007

1 commit

  • Some of the code has been gradually transitioned to using the proper
    struct request_queue, but there's lots left. So do a full sweet of
    the kernel and get rid of this typedef and replace its uses with
    the proper type.

    Signed-off-by: Jens Axboe

    Jens Axboe
     

14 Dec, 2006

1 commit


07 Jan, 2006

2 commits

  • Signed-off-by: Neil Brown
    Acked-by: Greg KH
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    NeilBrown
     
  • md supports multiple different RAID level, each being implemented by a
    'personality' (which is often in a separate module).

    These personalities have fairly artificial 'numbers'. The numbers
    are use to:
    1- provide an index into an array where the various personalities
    are recorded
    2- identify the module (via an alias) which implements are particular
    personality.

    Neither of these uses really justify the existence of personality numbers.
    The array can be replaced by a linked list which is searched (array lookup
    only happens very rarely). Module identification can be done using an alias
    based on level rather than 'personality' number.

    The current 'raid5' modules support two level (4 and 5) but only one
    personality. This slight awkwardness (which was handled in the mapping from
    level to personality) can be better handled by allowing raid5 to register 2
    personalities.

    With this change in place, the core md module does not need to have an
    exhaustive list of all possible personalities, so other personalities can be
    added independently.

    This patch also moves the check for chunksize being non-zero into the ->run
    routines for the personalities that need it, rather than having it in core-md.
    This has a side effect of allowing 'faulty' and 'linear' not to have a
    chunk-size set.

    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    NeilBrown
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds