1. 14 Jan, 2011 18 commits
  2. 13 Jan, 2011 22 commits
    • Tony Luck's avatar
      [IA64] fix build error - arch/ia64/kernel/perfmon.c · 09579770
      Tony Luck authored
      arch/ia64/kernel/perfmon.c:621: error: duplicate 'static'
      
      Introduced by commit c74a1cbb
      
          pass default dentry_operations to mount_pseudo()
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      09579770
    • NeilBrown's avatar
      md: Fix removal of extra drives when converting RAID6 to RAID5 · bf2cb0da
      NeilBrown authored
      When a RAID6 is converted to a RAID5, the extra drive should
      be discarded.  However it isn't due to a typo in a comparison.
      
      This bug was introduced in commit e93f68a1 in 2.6.35-rc4
      and is suitable for any -stable since than.
      
      As the extra drive is not removed, the 'degraded' counter is wrong and
      so the RAID5 will not respond correctly to a subsequent failure.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      bf2cb0da
    • NeilBrown's avatar
      md: range check slot number when manually adding a spare. · ba1b41b6
      NeilBrown authored
      When adding a spare to an active array, we should check the slot
      number, but allow it to be larger than raid_disks if a reshape
      is being prepared.
      
      Apply the same test when adding a device to an
      array-under-construction.  It already had most of the test in place,
      but not quite all.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      ba1b41b6
    • NeilBrown's avatar
      md/raid5: handle manually-added spares in start_reshape. · 1a940fce
      NeilBrown authored
      It is possible to manually add spares to specific slots before
      starting a reshape.
      raid5_start_reshape should recognised this possibility and include
      it in the accounting.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      1a940fce
    • Rémi Rérolle's avatar
      md: fix sync_completed reporting for very large drives (>2TB) · 13ae864b
      Rémi Rérolle authored
      The values exported in the sync_completed file are unsigned long, which
      overflows with very large drives, resulting in wrong values reported.
      
      Since sync_completed uses sectors as unit, we'll start getting wrong
      values with components larger than 2TB.
      
      This patch simply replaces the use of unsigned long by unsigned long long.
      Signed-off-by: default avatarRémi Rérolle <rrerolle@lacie.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      13ae864b
    • NeilBrown's avatar
      md: allow suspend_lo and suspend_hi to decrease as well as increase. · 23ddff37
      NeilBrown authored
      The sysfs attributes 'suspend_lo' and 'suspend_hi' describe a region
      to which read/writes are suspended so that the under lying data can be
      manipulated without user-space noticing.
      Currently the window they describe can only move forwards along the
      device.  However this is an unnecessary restriction which will cause
      problems with planned developments.
      So relax this restriction and allow these endpoints to move
      arbitrarily.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      23ddff37
    • NeilBrown's avatar
      md: Don't let implementation detail of curr_resync leak out through sysfs. · 75d3da43
      NeilBrown authored
      mddev->curr_resync has artificial values of '1' and '2' which are used
      by the code which ensures only one resync is happening at a time on
      any given device.
      
      These values are internal and should never be exposed to user-space
      (except when translated appropriately as in the 'pending' status in
      /proc/mdstat).
      
      Unfortunately they are as ->curr_resync is assigned to
      ->curr_resync_completed and that value is directly visible through
      sysfs.
      
      So change the assignments to ->curr_resync_completed to get the same
      valued from elsewhere in a form that doesn't have the magic '1' or '2'
      values.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      75d3da43
    • Jonathan Brassow's avatar
      md: separate meta and data devs · a6ff7e08
      Jonathan Brassow authored
      Allow the metadata to be on a separate device from the
      data.
      
      This doesn't mean the data and metadata will by on separate
      physical devices - it simply gives device-mapper and userspace
      tools more flexibility.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      a6ff7e08
    • Jonathan Brassow's avatar
      md-new-param-to_sync_page_io · ccebd4c4
      Jonathan Brassow authored
      Add new parameter to 'sync_page_io'.
      
      The new parameter allows us to distinguish between metadata and data
      operations.  This becomes important later when we add the ability to
      use separate devices for data and metadata.
      Signed-off-by: default avatarJonathan Brassow <jbrassow@redhat.com>
      ccebd4c4
    • Jonathan Brassow's avatar
      md-new-param-to-calc_dev_sboffset · 57b2caa3
      Jonathan Brassow authored
      When we allow for separate devices for data and metadata
      in a later patch, we will need to be able to calculate
      the superblock offset based on more than the bdev.
      Signed-off-by: default avatarJonathan Brassow <jbrassow@redhat.com>
      57b2caa3
    • NeilBrown's avatar
      md: Be more careful about clearing flags bit in ->recovery · 7ebc0be7
      NeilBrown authored
      Setting ->recovery to 0 is generally not a good idea as it could clear
      bits that shouldn't be cleared.  In particular, MD_RECOVERY_FROZEN
      should only be cleared on explicit request from user-space.
      
      So when we need to clear things, just clear the bits that need
      clearing.
      
      As there are a few different places which reap a resync process - and
      some do an incomplte job - factor out the code for doing the from
      md_check_recovery and call that function instead of open coding part
      of it.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Reported-by: default avatarJonathan Brassow <jbrassow@redhat.com>
      7ebc0be7
    • NeilBrown's avatar
      md: md_stop_writes requires mddev_lock. · defad61a
      NeilBrown authored
      As md_stop_writes manipulates the sync_thread and calls md_update_sb,
      it need to be called with mddev_lock held.
      
      In all internal cases it is, but the symbol is exported for dm-raid to
      call and in that case the lock won't be help.
      Do make an exported version which takes the lock, and an internal
      version which does not.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      defad61a
    • Jonathan Brassow's avatar
      md/raid5: use sysfs_notify_dirent_safe to avoid NULL pointer · 43c73ca4
      Jonathan Brassow authored
      With the module parameter 'start_dirty_degraded' set,
      raid5_spare_active() previously called sysfs_notify_dirent() with a NULL
      argument (rdev->sysfs_state) when a rebuild finished.
      Signed-off-by: default avatarJonathan Brassow <jbrassow@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      43c73ca4
    • NeilBrown's avatar
      md: Ensure no IO request to get md device before it is properly initialised. · 0ca69886
      NeilBrown authored
      When an md device is in the process of coming on line it is possible
      for an IO request (typically a partition table probe) to get through
      before the array is fully initialised, which can cause unexpected
      behaviour (e.g. a crash).
      
      So explicitly record when the array is ready for IO and don't allow IO
      through until then.
      
      There is no possibility for a similar problem when the array is going
      off-line as there must only be one 'open' at that time, and it is busy
      off-lining the array and so cannot send IO requests.  So no memory
      barrier is needed in md_stop()
      
      This has been a bug since commit 409c57f3 in 2.6.30 which
      introduced md_make_request.  Before then, each personality would
      register its own make_request_fn when it was ready.
      This is suitable for any stable kernel from 2.6.30.y onwards.
      
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Reported-by: default avatar"Hawrylewicz Czarnowski, Przemyslaw" <przemyslaw.hawrylewicz.czarnowski@intel.com>
      0ca69886
    • Joe Perches's avatar
      067032bc
    • NeilBrown's avatar
      md: fix regression resulting in delays in clearing bits in a bitmap · 6c987910
      NeilBrown authored
      commit 589a594b (2.6.37-rc4) fixed a problem were md_thread would
      sometimes call the ->run function at a bad time.
      
      If an error is detected during array start up after the md_thread has
      been started, the md_thread is killed.  This resulted in the ->run
      function being called once.  However the array may not be in a state
      that it is safe to call ->run.
      
      However the fix imposed meant that  ->run was not called on a timeout.
      This means that when an array goes idle, bitmap bits do not get
      cleared promptly.  While the array is busy the bits will still be
      cleared when appropriate so this is not very serious.  There is no
      risk to data.
      
      Change the test so that we only avoid calling ->run when the thread
      is being stopped.  This more explicitly addresses the problem situation.
      
      This is suitable for 2.6.37-stable and any -stable kernel to which
      589a594b was applied.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      6c987910
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/avr32-2.6 · 2a86cb7c
      Linus Torvalds authored
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/avr32-2.6:
        avr32: update default configuration files for Atmel boards
        avr32: Convert to clocksource_register_hz
        avr32: make architecture sys_clone prototype match asm-generic prototype
        avr32: use syscall prototypes from asm-generic instead of arch
        avr32: disable kprobes for all default configurations
        avr32: boards: setup: use IS_ERR() instead of NULL check
      2a86cb7c
    • Trond Myklebust's avatar
      NFS: Fix NFSv3 exclusive open semantics · 8a0eebf6
      Trond Myklebust authored
      Commit c0204fd2 (NFS: Clean up
      nfs4_proc_create()) broke NFSv3 exclusive open by removing the code
      that passes the O_EXCL flag down to nfs3_proc_create(). This patch
      reverts that offending hunk from the original commit.
      Reported-by: default avatarNick Bowler <nbowler@elliptictech.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@kernel.org    [2.6.37]
      Tested-by: default avatarNick Bowler <nbowler@elliptictech.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8a0eebf6
    • NeilBrown's avatar
      dm: raid456 basic support · 9d09e663
      NeilBrown authored
      This patch is the skeleton for the DM target that will be
      the bridge from DM to MD (initially RAID456 and later RAID1).  It
      provides a way to use device-mapper interfaces to the MD RAID456
      drivers.
      
      As with all device-mapper targets, the nominal public interfaces are the
      constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
      and STATUSTYPE_TABLE).  The CTR table looks like the following:
      
      1: <s> <l> raid \
      2:	<raid_type> <#raid_params> <raid_params> \
      3:	<#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
      
      Line 1 contains the standard first three arguments to any device-mapper
      target - the start, length, and target type fields.  The target type in
      this case is "raid".
      
      Line 2 contains the arguments that define the particular raid
      type/personality/level, the required arguments for that raid type, and
      any optional arguments.  Possible raid types include: raid4, raid5_la,
      raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc.  (again, raid1 is
      planned for the future.)  The list of required and optional parameters
      is the same for all the current raid types.  The required parameters are
      positional, while the optional parameters are given as key/value pairs.
      The possible parameters are as follows:
       <chunk_size>		Chunk size in sectors.
       [[no]sync]		Force/Prevent RAID initialization
       [rebuild <idx>]	Rebuild the drive indicated by the index
       [daemon_sleep <ms>]	Time between bitmap daemon work to clear bits
       [min_recovery_rate <kB/sec/disk>]	Throttle RAID initialization
       [max_recovery_rate <kB/sec/disk>]	Throttle RAID initialization
       [max_write_behind <value>]		See '-write-behind=' (man mdadm)
       [stripe_cache <sectors>]		Stripe cache size for higher RAIDs
      
      Line 3 contains the list of devices that compose the array in
      metadata/data device pairs.  If the metadata is stored separately, a '-'
      is given for the metadata device position.  If a drive has failed or is
      missing at creation time, a '-' can be given for both the metadata and
      data drives for a given position.
      
      Examples:
      # RAID4 - 4 data drives, 1 parity
      # No metadata devices specified to hold superblock/bitmap info
      # Chunk size of 1MiB
      # (Lines separated for easy reading)
      0 1960893648 raid \
      	raid4 1 2048 \
      	5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
      
      # RAID4 - 4 data drives, 1 parity (no metadata devices)
      # Chunk size of 1MiB, force RAID initialization,
      #	min recovery rate at 20 kiB/sec/disk
      0 1960893648 raid \
              raid4 4 2048 min_recovery_rate 20 sync\
              5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
      
      Performing a 'dmsetup table' should display the CTR table used to
      construct the mapping (with possible reordering of optional
      parameters).
      
      Performing a 'dmsetup status' will yield information on the state and
      health of the array.  The output is as follows:
      1: <s> <l> raid \
      2:	<raid_type> <#devices> <1 health char for each dev> <resync_ratio>
      
      Line 1 is standard DM output.  Line 2 is best shown by example:
      	0 1960893648 raid raid4 5 AAAAA 2/490221568
      Here we can see the RAID type is raid4, there are 5 devices - all of
      which are 'A'live, and the array is 2/490221568 complete with recovery.
      
      Cc: linux-raid@vger.kernel.org
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarJonathan Brassow <jbrassow@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      9d09e663
    • NeilBrown's avatar
      dm: per target unplug callback support · 99d03c14
      NeilBrown authored
      Add per-target unplug callback support.
      
      Cc: linux-raid@vger.kernel.org
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarJonathan Brassow <jbrassow@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      99d03c14
    • NeilBrown's avatar
      dm: introduce target callbacks and congestion callback · 9d357b07
      NeilBrown authored
      DM currently implements congestion checking by checking on congestion
      in each component device.  For raid456 we need to also check if the
      stripe cache is congested.
      
      Add per-target congestion checker callback support.
      
      Extending the target_callbacks structure with additional callback
      functions allows for establishing multiple callbacks per-target (a
      callback is also needed for unplug).
      
      Cc: linux-raid@vger.kernel.org
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarJonathan Brassow <jbrassow@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      9d357b07
    • Chandra Seetharaman's avatar
      dm mpath: delay activate_path retry on SCSI_DH_RETRY · 4e2d19e4
      Chandra Seetharaman authored
      This patch adds a user-configurable 'pg_init_delay_msecs' feature.  Use
      this feature to specify the number of milliseconds to delay before
      retrying scsi_dh_activate, when SCSI_DH_RETRY is returned.
      
      SCSI Device Handlers return SCSI_DH_IMM_RETRY if we could retry
      activation immediately and SCSI_DH_RETRY in cases where it is better to
      retry after some delay.
      
      Currently we immediately retry scsi_dh_activate irrespective of
      SCSI_DH_IMM_RETRY and SCSI_DH_RETRY.
      
      The 'pg_init_delay_msecs' feature may be provided during table create or
      load, e.g.:
          dmsetup create --table "0 20971520 multipath 3 queue_if_no_path \
      	pg_init_delay_msecs 2500 ..." mpatha
      
      The default for 'pg_init_delay_msecs' is 2000 milliseconds.
      Maximum configurable delay is 60000 milliseconds.  Specifying a
      'pg_init_delay_msecs' of 0 will cause immediate retry.
      Signed-off-by: default avatarNikanth Karthikesan <knikanth@suse.de>
      Signed-off-by: default avatarChandra Seetharaman <sekharan@us.ibm.com>
      Acked-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      4e2d19e4