group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1907262@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package linux - 5.4.0-58.64

---------------
linux (5.4.0-58.64) focal; urgency=medium

  * focal/linux: 5.4.0-58.64 -proposed tracker (LP: #1907390)

  * Packaging resync (LP: #1786013)
    - update dkms package versions

  * raid10: discard leads to corrupted file system (LP: #1907262)
    - Revert "dm raid: remove unnecessary discard limits for raid10"
    - Revert "dm raid: fix discard limits for raid1 and raid10"
    - Revert "md/raid10: improve discard request for far layout"
    - Revert "md/raid10: improve raid10 discard request"
    - Revert "md/raid10: pull codes that wait for blocked dev into one function"
    - Revert "md/raid10: extend r10bio devs to raid disks"
    - Revert "md: add md_submit_discard_bio() for submitting discard bio"

 -- Khalid Elmously <khalid.elmously@xxxxxxxxxxxxx>  Wed, 09 Dec 2020
02:10:30 -0500

** Changed in: linux (Ubuntu Focal)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1907262

Title:
  raid10: discard leads to corrupted file system

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Trusty:
  Invalid
Status in linux source package in Xenial:
  Invalid
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Focal:
  Fix Released
Status in linux source package in Groovy:
  Fix Released

Bug description:
  Seems to be closely related to
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578

  After updating the Ubuntu 18.04 kernel from 4.15.0-124 to 4.15.0-126
  the fstrim command triggered by fstrim.timer causes a severe number of
  mismatches between two RAID10 component devices.

  This bug affects several machines in our company with different HW
  configurations (All using ECC RAM). Both, NVMe and SATA SSDs are
  affected.

  How to reproduce:
   - Create a RAID10 LVM and filesystem on two SSDs
      mdadm -C -v -l10 -n2 -N "lv-raid" -R /dev/md0 /dev/nvme0n1p2 /dev/nvme1n1p2
      pvcreate -ff -y /dev/md0
      vgcreate -f -y VolGroup /dev/md0
      lvcreate -n root    -L 100G -ay -y VolGroup
      mkfs.ext4 /dev/VolGroup/root
      mount /dev/VolGroup/root /mnt
   - Write some data, sync and delete it
      dd if=/dev/zero of=/mnt/data.raw bs=4K count=1M
      sync
      rm /mnt/data.raw
   - Check the RAID device
      echo check >/sys/block/md0/md/sync_action
   - After finishing (see /proc/mdstat), check the mismatch_cnt (should be 0):
      cat /sys/block/md0/md/mismatch_cnt
   - Trigger the bug
      fstrim /mnt
   - Re-Check the RAID device
      echo check >/sys/block/md0/md/sync_action
   - After finishing (see /proc/mdstat), check the mismatch_cnt (probably in the range of N*10000):
      cat /sys/block/md0/md/mismatch_cnt

  After investigating this issue on several machines it *seems* that the
  first drive does the trim correctly while the second one goes wild. At
  least the number and severity of errors found by a  USB stick live
  session fsck.ext4 suggests this.

  To perform the single drive evaluation the RAID10 was started using a single drive at once:
    mdadm --assemble /dev/md127 /dev/nvme0n1p2
    mdadm --run /dev/md127
    fsck.ext4 -n -f /dev/VolGroup/root

    vgchange -a n /dev/VolGroup
    mdadm --stop /dev/md127

    mdadm --assemble /dev/md127 /dev/nvme1n1p2
    mdadm --run /dev/md127
    fsck.ext4 -n -f /dev/VolGroup/root

  When starting these fscks without -n, on the first device it seems the
  directory structure is OK while on the second device there is only the
  lost+found folder left.

  Side-note: Another machine using HWE kernel 5.4.0-56 (after using -53
  before) seems to have a quite similar issue.

  Unfortunately the risk/regression assessment in the aforementioned bug
  is not complete: the workaround only mitigates the issues during FS
  creation. This bug on the other hand is triggered by a weekly service
  (fstrim) causing severe file system corruption.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1907262/+subscriptions