1. 15 7月, 2022 1 次提交
  2. 23 5月, 2022 1 次提交
  3. 26 4月, 2022 1 次提交
    • M
      md: Set MD_BROKEN for RAID1 and RAID10 · 9631abdb
      Mariusz Tkaczyk 提交于
      There is no direct mechanism to determine raid failure outside
      personality. It is done by checking rdev->flags after executing
      md_error(). If "faulty" flag is not set then -EBUSY is returned to
      userspace. -EBUSY means that array will be failed after drive removal.
      
      Mdadm has special routine to handle the array failure and it is executed
      if -EBUSY is returned by md.
      
      There are at least two known reasons to not consider this mechanism
      as correct:
      1. drive can be removed even if array will be failed[1].
      2. -EBUSY seems to be wrong status. Array is not busy, but removal
         process cannot proceed safe.
      
      -EBUSY expectation cannot be removed without breaking compatibility
      with userspace. In this patch first issue is resolved by adding support
      for MD_BROKEN flag for RAID1 and RAID10. Support for RAID456 is added in
      next commit.
      
      The idea is to set the MD_BROKEN if we are sure that raid is in failed
      state now. This is done in each error_handler(). In md_error() MD_BROKEN
      flag is checked. If is set, then -EBUSY is returned to userspace.
      
      As in previous commit, it causes that #mdadm --set-faulty is able to
      fail array. Previously proposed workaround is valid if optional
      functionality[1] is disabled.
      
      [1] commit 9a567843("md: allow last device to be forcibly removed from
          RAID1/RAID10.")
      Reviewd-by: NXiao Ni <xni@redhat.com>
      Signed-off-by: NMariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
      Signed-off-by: NSong Liu <song@kernel.org>
      9631abdb
  4. 18 4月, 2022 3 次提交
  5. 09 3月, 2022 1 次提交
  6. 08 3月, 2022 1 次提交
  7. 07 3月, 2022 1 次提交
  8. 23 2月, 2022 1 次提交
  9. 04 2月, 2022 1 次提交
  10. 02 2月, 2022 2 次提交
  11. 07 1月, 2022 2 次提交
  12. 04 1月, 2022 1 次提交
    • S
      md/raid1: fix missing bitmap update w/o WriteMostly devices · 46669e86
      Song Liu 提交于
      commit [1] causes missing bitmap updates when there isn't any WriteMostly
      devices.
      
      Detailed steps to reproduce by Norbert (which somehow didn't make to lore):
      
         # setup md10 (raid1) with two drives (1 GByte sparse files)
         dd if=/dev/zero of=disk1 bs=1024k seek=1024 count=0
         dd if=/dev/zero of=disk2 bs=1024k seek=1024 count=0
      
         losetup /dev/loop11 disk1
         losetup /dev/loop12 disk2
      
         mdadm --create /dev/md10 --level=1 --raid-devices=2 /dev/loop11 /dev/loop12
      
         # add bitmap (aka write-intent log)
         mdadm /dev/md10 --grow --bitmap=internal
      
         echo check > /sys/block/md10/md/sync_action
      
         root:# cat /sys/block/md10/md/mismatch_cnt
         0
         root:#
      
         # remove member drive disk2 (loop12)
         mdadm /dev/md10 -f loop12 ; mdadm /dev/md10 -r loop12
      
         # modify degraded md device
         dd if=/dev/urandom of=/dev/md10 bs=512 count=1
      
         # no blocks recorded as out of sync on the remaining member disk1/loop11
         root:# mdadm -X /dev/loop11 | grep Bitmap
                   Bitmap : 16 bits (chunks), 0 dirty (0.0%)
         root:#
      
         # re-add disk2, nothing synced because of empty bitmap
         mdadm /dev/md10 --re-add /dev/loop12
      
         # check integrity again
         echo check > /sys/block/md10/md/sync_action
      
         # disk1 and disk2 are no longer in sync, reads return differend data
         root:# cat /sys/block/md10/md/mismatch_cnt
         128
         root:#
      
         # clean up
         mdadm -S /dev/md10
         losetup -d /dev/loop11
         losetup -d /dev/loop12
         rm disk1 disk2
      
      Fix this by moving the WriteMostly check to the if condition for
      alloc_behind_master_bio().
      
      [1] commit fd3b6975 ("md/raid1: only allocate write behind bio for WriteMostly device")
      Fixes: fd3b6975 ("md/raid1: only allocate write behind bio for WriteMostly device")
      Cc: stable@vger.kernel.org # v5.12+
      Cc: Guoqing Jiang <guoqing.jiang@linux.dev>
      Cc: Jens Axboe <axboe@kernel.dk>
      Reported-by: NNorbert Warmuth <nwarmuth@t-online.de>
      Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSong Liu <song@kernel.org>
      46669e86
  13. 19 10月, 2021 2 次提交
  14. 28 8月, 2021 1 次提交
    • G
      raid1: ensure write behind bio has less than BIO_MAX_VECS sectors · 6607cd31
      Guoqing Jiang 提交于
      We can't split write behind bio with more than BIO_MAX_VECS sectors,
      otherwise the below call trace was triggered because we could allocate
      oversized write behind bio later.
      
      [ 8.097936] bvec_alloc+0x90/0xc0
      [ 8.098934] bio_alloc_bioset+0x1b3/0x260
      [ 8.099959] raid1_make_request+0x9ce/0xc50 [raid1]
      [ 8.100988] ? __bio_clone_fast+0xa8/0xe0
      [ 8.102008] md_handle_request+0x158/0x1d0 [md_mod]
      [ 8.103050] md_submit_bio+0xcd/0x110 [md_mod]
      [ 8.104084] submit_bio_noacct+0x139/0x530
      [ 8.105127] submit_bio+0x78/0x1d0
      [ 8.106163] ext4_io_submit+0x48/0x60 [ext4]
      [ 8.107242] ext4_writepages+0x652/0x1170 [ext4]
      [ 8.108300] ? do_writepages+0x41/0x100
      [ 8.109338] ? __ext4_mark_inode_dirty+0x240/0x240 [ext4]
      [ 8.110406] do_writepages+0x41/0x100
      [ 8.111450] __filemap_fdatawrite_range+0xc5/0x100
      [ 8.112513] file_write_and_wait_range+0x61/0xb0
      [ 8.113564] ext4_sync_file+0x73/0x370 [ext4]
      [ 8.114607] __x64_sys_fsync+0x33/0x60
      [ 8.115635] do_syscall_64+0x33/0x40
      [ 8.116670] entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      Thanks for the comment from Christoph.
      
      [1]. https://bugs.archlinux.org/task/70992
      
      Cc: stable@vger.kernel.org # v5.12+
      Reported-by: NJens Stutte <jens@chianterastutte.eu>
      Tested-by: NJens Stutte <jens@chianterastutte.eu>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NGuoqing Jiang <jiangguoqing@kylinos.cn>
      Signed-off-by: NSong Liu <songliubraving@fb.com>
      6607cd31
  15. 24 7月, 2021 1 次提交
  16. 15 6月, 2021 2 次提交
  17. 24 4月, 2021 1 次提交
  18. 28 1月, 2021 1 次提交
  19. 25 1月, 2021 1 次提交
  20. 05 12月, 2020 1 次提交
  21. 09 7月, 2020 1 次提交
  22. 01 7月, 2020 1 次提交
  23. 14 5月, 2020 1 次提交
    • D
      md/raid1: release pending accounting for an I/O only after write-behind is also finished · c91114c2
      David Jeffery 提交于
      When using RAID1 and write-behind, md can deadlock when errors occur. With
      write-behind, r1bio structs can be accounted by raid1 as queued but not
      counted as pending. The pending count is dropped when the original bio is
      returned complete but write-behind for the r1bio may still be active.
      
      This breaks the accounting used in some conditions to know when the raid1
      md device has reached an idle state. It can result in calls to
      freeze_array deadlocking. freeze_array will never complete from a negative
      "unqueued" value being calculated due to a queued count larger than the
      pending count.
      
      To properly account for write-behind, move the call to allow_barrier from
      call_bio_endio to raid_end_bio_io. When using write-behind, md can call
      call_bio_endio before all write-behind I/O is complete. Using
      raid_end_bio_io for the point to call allow_barrier will release the
      pending count at a point where all I/O for an r1bio, even write-behind, is
      done.
      Signed-off-by: NDavid Jeffery <djeffery@redhat.com>
      Signed-off-by: NSong Liu <songliubraving@fb.com>
      c91114c2
  24. 14 1月, 2020 5 次提交
  25. 12 12月, 2019 1 次提交
  26. 12 11月, 2019 1 次提交
  27. 25 10月, 2019 1 次提交
    • D
      md: improve handling of bio with REQ_PREFLUSH in md_flush_request() · 775d7831
      David Jeffery 提交于
      If pers->make_request fails in md_flush_request(), the bio is lost. To
      fix this, pass back a bool to indicate if the original make_request call
      should continue to handle the I/O and instead of assuming the flush logic
      will push it to completion.
      
      Convert md_flush_request to return a bool and no longer calls the raid
      driver's make_request function.  If the return is true, then the md flush
      logic has or will complete the bio and the md make_request call is done.
      If false, then the md make_request function needs to keep processing like
      it is a normal bio. Let the original call to md_handle_request handle any
      need to retry sending the bio to the raid driver's make_request function
      should it be needed.
      
      Also mark md_flush_request and the make_request function pointer as
      __must_check to issue warnings should these critical return values be
      ignored.
      
      Fixes: 2bc13b83 ("md: batch flush requests.")
      Cc: stable@vger.kernel.org # # v4.19+
      Cc: NeilBrown <neilb@suse.com>
      Signed-off-by: NDavid Jeffery <djeffery@redhat.com>
      Reviewed-by: NXiao Ni <xni@redhat.com>
      Signed-off-by: NSong Liu <songliubraving@fb.com>
      775d7831
  28. 04 9月, 2019 1 次提交
    • Y
      md/raid1: fail run raid1 array when active disk less than one · 07f1a685
      Yufen Yu 提交于
      When run test case:
        mdadm -CR /dev/md1 -l 1 -n 4 /dev/sd[a-d] --assume-clean --bitmap=internal
        mdadm -S /dev/md1
        mdadm -A /dev/md1 /dev/sd[b-c] --run --force
      
        mdadm --zero /dev/sda
        mdadm /dev/md1 -a /dev/sda
      
        echo offline > /sys/block/sdc/device/state
        echo offline > /sys/block/sdb/device/state
        sleep 5
        mdadm -S /dev/md1
      
        echo running > /sys/block/sdb/device/state
        echo running > /sys/block/sdc/device/state
        mdadm -A /dev/md1 /dev/sd[a-c] --run --force
      
      mdadm run fail with kernel message as follow:
      [  172.986064] md: kicking non-fresh sdb from array!
      [  173.004210] md: kicking non-fresh sdc from array!
      [  173.022383] md/raid1:md1: active with 0 out of 4 mirrors
      [  173.022406] md1: failed to create bitmap (-5)
      
      In fact, when active disk in raid1 array less than one, we
      need to return fail in raid1_run().
      Reviewed-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NYufen Yu <yuyufen@huawei.com>
      Signed-off-by: NSong Liu <songliubraving@fb.com>
      07f1a685
  29. 08 8月, 2019 2 次提交