[Bug 1850540] Re: multi-zone raid0 corruption
** Changed in: ubuntu-release-notes Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
The Precise Pangolin has reached end of life, so this bug will not be fixed for that release ** Changed in: mdadm (Ubuntu Precise) Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
The Precise Pangolin has reached end of life, so this bug will not be fixed for that release ** Changed in: linux (Ubuntu Precise) Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
** Changed in: linux (Ubuntu Disco) Status: Fix Committed => Won't Fix ** Changed in: mdadm (Ubuntu Disco) Status: Fix Committed => Won't Fix -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
This bug was fixed in the package linux - 5.4.0-18.22 --- linux (5.4.0-18.22) focal; urgency=medium * focal/linux: 5.4.0-18.22 -proposed tracker (LP: #1866488) * Packaging resync (LP: #1786013) - [Packaging] resync getabis - [Packaging] update helper scripts * Add sysfs attribute to show remapped NVMe (LP: #1863621) - SAUCE: ata: ahci: Add sysfs attribute to show remapped NVMe device count * [20.04 FEAT] Compression improvements in Linux kernel (LP: #1830208) - lib/zlib: add s390 hardware support for kernel zlib_deflate - s390/boot: rename HEAP_SIZE due to name collision - lib/zlib: add s390 hardware support for kernel zlib_inflate - s390/boot: add dfltcc= kernel command line parameter - lib/zlib: add zlib_deflate_dfltcc_enabled() function - btrfs: use larger zlib buffer for s390 hardware compression - [Config] Introducing s390x specific kernel config option CONFIG_ZLIB_DFLTCC * [UBUNTU 20.04] s390x/pci: increase CONFIG_PCI_NR_FUNCTIONS to 512 in kernel config (LP: #1866056) - [Config] Increase CONFIG_PCI_NR_FUNCTIONS from 64 to 512 starting with focal on s390x * CONFIG_IP_MROUTE_MULTIPLE_TABLES is not set (LP: #1865332) - [Config] CONFIG_IP_MROUTE_MULTIPLE_TABLES=y * Dell XPS 13 9300 Intel 1650S wifi [34f0:1651] fails to load firmware (LP: #1865962) - iwlwifi: remove IWL_DEVICE_22560/IWL_DEVICE_FAMILY_22560 - iwlwifi: 22000: fix some indentation - iwlwifi: pcie: rx: use rxq queue_size instead of constant - iwlwifi: allocate more receive buffers for HE devices - iwlwifi: remove some outdated iwl22000 configurations - iwlwifi: assume the driver_data is a trans_cfg, but allow full cfg * [FOCAL][REGRESSION] Intel Gen 9 brightness cannot be controlled (LP: #1861521) - Revert "USUNTU: SAUCE: drm/i915: Force DPCD backlight mode on Dell Precision 4K sku" - Revert "UBUNTU: SAUCE: drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED panel" - SAUCE: drm/dp: Introduce EDID-based quirks - SAUCE: drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED panel - SAUCE: drm/i915: Force DPCD backlight mode for some Dell CML 2020 panels * [20.04 FEAT] Enable proper kprobes on ftrace support (LP: #1865858) - s390/ftrace: save traced function caller - s390: support KPROBES_ON_FTRACE * alsa/sof: load different firmware on different platforms (LP: #1857409) - ASoC: SOF: Intel: hda: use fallback for firmware name - ASoC: Intel: acpi-match: split CNL tables in three - ASoC: SOF: Intel: Fix CFL and CML FW nocodec binary names. * [UBUNTU 20.04] Enable CONFIG_NET_SWITCHDEV in kernel config for s390x starting with focal (LP: #1865452) - [Config] Enable CONFIG_NET_SWITCHDEV in kernel config for s390x starting with focal * Focal update: v5.4.24 upstream stable release (LP: #1866333) - io_uring: grab ->fs as part of async offload - EDAC: skx_common: downgrade message importance on missing PCI device - net: dsa: b53: Ensure the default VID is untagged - net: fib_rules: Correctly set table field when table number exceeds 8 bits - net: macb: ensure interface is not suspended on at91rm9200 - net: mscc: fix in frame extraction - net: phy: restore mdio regs in the iproc mdio driver - net: sched: correct flower port blocking - net/tls: Fix to avoid gettig invalid tls record - nfc: pn544: Fix occasional HW initialization failure - qede: Fix race between rdma destroy workqueue and link change event - Revert "net: dev: introduce support for sch BYPASS for lockless qdisc" - udp: rehash on disconnect - sctp: move the format error check out of __sctp_sf_do_9_1_abort - bnxt_en: Improve device shutdown method. - bnxt_en: Issue PCIe FLR in kdump kernel to cleanup pending DMAs. - bonding: add missing netdev_update_lockdep_key() - net: export netdev_next_lower_dev_rcu() - bonding: fix lockdep warning in bond_get_stats() - ipv6: Fix route replacement with dev-only route - ipv6: Fix nlmsg_flags when splitting a multipath route - ipmi:ssif: Handle a possible NULL pointer reference - drm/msm: Set dma maximum segment size for mdss - sched/core: Don't skip remote tick for idle CPUs - timers/nohz: Update NOHZ load in remote tick - sched/fair: Prevent unlimited runtime on throttled group - dax: pass NOWAIT flag to iomap_apply - mac80211: consider more elements in parsing CRC - cfg80211: check wiphy driver existence for drvinfo report - s390/zcrypt: fix card and queue total counter wrap - qmi_wwan: re-add DW5821e pre-production variant - qmi_wwan: unconditionally reject 2 ep interfaces - NFSv4: Fix races between open and dentry revalidation - perf/smmuv3: Use platform_get_irq_optional() for wired interrupt - perf/x86/intel: Add Elkhart Lake support - perf/x86/cstate: Add Tremont
[Bug 1850540] Re: multi-zone raid0 corruption
This bug was fixed in the package linux - 4.4.0-174.204 --- linux (4.4.0-174.204) xenial; urgency=medium * xenial/linux: 4.4.0-174.204 -proposed tracker (LP: #1861122) * Xenial update: 4.4.211 upstream stable release (LP: #1860681) - hidraw: Return EPOLLOUT from hidraw_poll - HID: hidraw: Fix returning EPOLLOUT from hidraw_poll - HID: hidraw, uhid: Always report EPOLLOUT - cfg80211/mac80211: make ieee80211_send_layer2_update a public function - mac80211: Do not send Layer 2 Update frame before authorization - media: usb:zr364xx:Fix KASAN:null-ptr-deref Read in zr364xx_vidioc_querycap - p54usb: Fix race between disconnect and firmware loading - ALSA: line6: Fix write on zero-sized buffer - ALSA: line6: Fix memory leak at line6_init_pcm() error path - xen: let alloc_xenballooned_pages() fail if not enough memory free - wimax: i2400: fix memory leak - wimax: i2400: Fix memory leak in i2400m_op_rfkill_sw_toggle - ext4: fix use-after-free race with debug_want_extra_isize - ext4: add more paranoia checking in ext4_expand_extra_isize handling - rtc: mt6397: fix alarm register overwrite - iommu: Remove device link to group on failure - gpio: Fix error message on out-of-range GPIO in lookup table - hsr: reset network header when supervision frame is created - cifs: Adjust indentation in smb2_open_file - RDMA/srpt: Report the SCSI residual to the initiator - scsi: enclosure: Fix stale device oops with hot replug - scsi: sd: Clear sdkp->protection_type if disk is reformatted without PI - platform/x86: asus-wmi: Fix keyboard brightness cannot be set to 0 - iio: imu: adis16480: assign bias value only if operation succeeded - mei: fix modalias documentation - clk: samsung: exynos5420: Preserve CPU clocks configuration during suspend/resume - compat_ioctl: handle SIOCOUTQNSD - tty: serial: imx: use the sg count from dma_map_sg - tty: serial: pch_uart: correct usage of dma_unmap_sg - media: exynos4-is: Fix recursive locking in isp_video_release() - spi: atmel: fix handling of cs_change set on non-last xfer - rtlwifi: Remove unnecessary NULL check in rtl_regd_init - rtc: msm6242: Fix reading of 10-hour digit - rseq/selftests: Turn off timeout setting - hexagon: work around compiler crash - ocfs2: call journal flush to mark journal as empty after journal recovery when mount - ALSA: seq: Fix racy access for queue timer in proc read - Fix built-in early-load Intel microcode alignment - block: fix an integer overflow in logical block size - USB: serial: simple: Add Motorola Solutions TETRA MTP3xxx and MTP85xx - USB: serial: opticon: fix control-message timeouts - USB: serial: suppress driver bind attributes - USB: serial: ch341: handle unbound port at reset_resume - USB: serial: io_edgeport: add missing active-port sanity check - USB: serial: quatech2: handle unbound ports - scsi: mptfusion: Fix double fetch bug in ioctl - usb: core: hub: Improved device recognition on remote wakeup - x86/efistub: Disable paging at mixed mode entry - mm/page-writeback.c: avoid potential division by zero in wb_min_max_ratio() - net: stmmac: 16KB buffer must be 16 byte aligned - net: stmmac: Enable 16KB buffer size - USB: serial: io_edgeport: use irqsave() in USB's complete callback - USB: serial: io_edgeport: handle unbound ports on URB completion - USB: serial: keyspan: handle unbound ports - scsi: fnic: use kernel's '%pM' format option to print MAC - scsi: fnic: fix invalid stack access - arm64: dts: agilex/stratix10: fix pmu interrupt numbers - netfilter: fix a use-after-free in mtype_destroy() - batman-adv: Fix DAT candidate selection on little endian systems - macvlan: use skb_reset_mac_header() in macvlan_queue_xmit() - r8152: add missing endpoint sanity check - tcp: fix marked lost packets not being retransmitted - net: usb: lan78xx: limit size of local TSO packets - xen/blkfront: Adjust indentation in xlvbd_alloc_gendisk - cw1200: Fix a signedness bug in cw1200_load_firmware() - cfg80211: check for set_wiphy_params - scsi: esas2r: unlock on error in esas2r_nvram_read_direct() - scsi: qla4xxx: fix double free bug - scsi: bnx2i: fix potential use after free - scsi: target: core: Fix a pr_debug() argument - scsi: core: scsi_trace: Use get_unaligned_be*() - perf probe: Fix wrong address verification - regulator: ab8500: Remove SYSCLKREQ from enum ab8505_regulator_id - Linux 4.4.211 * Xenial update: 4.4.210 upstream stable release (LP: #1859865) - chardev: Avoid potential use-after-free in 'chrdev_open()' - usb: chipidea: host: Disable port power only if previously enabled - ALSA: usb-audio: Apply the sample rate quirk for Bose Companion 5 - kernel/trace: Fix do not unregister tracepoints when
[Bug 1850540] Re: multi-zone raid0 corruption
This bug was fixed in the package linux - 4.15.0-88.88 --- linux (4.15.0-88.88) bionic; urgency=medium * bionic/linux: 4.15.0-88.88 -proposed tracker (LP: #1862824) * Segmentation fault (kernel oops) with memory-hotplug in ubuntu_kernel_selftests on Bionic kernel (LP: #1862312) - Revert "mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock" - mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock linux (4.15.0-87.87) bionic; urgency=medium * bionic/linux: 4.15.0-87.87 -proposed tracker (LP: #1861165) * Bionic update: upstream stable patchset 2020-01-22 (LP: #1860602) - scsi: lpfc: Fix discovery failures when target device connectivity bounces - scsi: mpt3sas: Fix clear pending bit in ioctl status - scsi: lpfc: Fix locking on mailbox command completion - Input: atmel_mxt_ts - disable IRQ across suspend - iommu/tegra-smmu: Fix page tables in > 4 GiB memory - scsi: target: compare full CHAP_A Algorithm strings - scsi: lpfc: Fix SLI3 hba in loop mode not discovering devices - scsi: csiostor: Don't enable IRQs too early - powerpc/pseries: Mark accumulate_stolen_time() as notrace - powerpc/pseries: Don't fail hash page table insert for bolted mapping - powerpc/tools: Don't quote $objdump in scripts - dma-debug: add a schedule point in debug_dma_dump_mappings() - clocksource/drivers/asm9260: Add a check for of_clk_get - powerpc/security/book3s64: Report L1TF status in sysfs - powerpc/book3s64/hash: Add cond_resched to avoid soft lockup warning - ext4: update direct I/O read lock pattern for IOCB_NOWAIT - jbd2: Fix statistics for the number of logged blocks - scsi: tracing: Fix handling of TRANSFER LENGTH == 0 for READ(6) and WRITE(6) - scsi: lpfc: Fix duplicate unreg_rpi error in port offline flow - f2fs: fix to update dir's i_pino during cross_rename - clk: qcom: Allow constant ratio freq tables for rcg - irqchip/irq-bcm7038-l1: Enable parent IRQ if necessary - irqchip: ingenic: Error out if IRQ domain creation failed - fs/quota: handle overflows of sysctl fs.quota.* and report as unsigned long - scsi: lpfc: fix: Coverity: lpfc_cmpl_els_rsp(): Null pointer dereferences - scsi: ufs: fix potential bug which ends in system hang - powerpc/pseries/cmm: Implement release() function for sysfs device - powerpc/security: Fix wrong message when RFI Flush is disable - scsi: atari_scsi: sun3_scsi: Set sg_tablesize to 1 instead of SG_NONE - clk: pxa: fix one of the pxa RTC clocks - bcache: at least try to shrink 1 node in bch_mca_scan() - HID: logitech-hidpp: Silence intermittent get_battery_capacity errors - libnvdimm/btt: fix variable 'rc' set but not used - HID: Improve Windows Precision Touchpad detection. - scsi: pm80xx: Fix for SATA device discovery - scsi: ufs: Fix error handing during hibern8 enter - scsi: scsi_debug: num_tgts must be >= 0 - scsi: NCR5380: Add disconnect_mask module parameter - scsi: iscsi: Don't send data to unbound connection - scsi: target: iscsi: Wait for all commands to finish before freeing a session - gpio: mpc8xxx: Don't overwrite default irq_set_type callback - apparmor: fix unsigned len comparison with less than zero - scripts/kallsyms: fix definitely-lost memory leak - cdrom: respect device capabilities during opening action - perf script: Fix brstackinsn for AUXTRACE - perf regs: Make perf_reg_name() return "unknown" instead of NULL - s390/zcrypt: handle new reply code FILTERED_BY_HYPERVISOR - libfdt: define INT32_MAX and UINT32_MAX in libfdt_env.h - s390/cpum_sf: Check for SDBT and SDB consistency - ocfs2: fix passing zero to 'PTR_ERR' warning - kernel: sysctl: make drop_caches write-only - userfaultfd: require CAP_SYS_PTRACE for UFFD_FEATURE_EVENT_FORK - x86/mce: Fix possibly incorrect severity calculation on AMD - net, sysctl: Fix compiler warning when only cBPF is present - netfilter: nf_queue: enqueue skbs with NULL dst - ALSA: hda - Downgrade error message for single-cmd fallback - bonding: fix active-backup transition after link failure - perf strbuf: Remove redundant va_end() in strbuf_addv() - Make filldir[64]() verify the directory entry filename is valid - filldir[64]: remove WARN_ON_ONCE() for bad directory entries - netfilter: ebtables: compat: reject all padding in matches/watchers - 6pack,mkiss: fix possible deadlock - netfilter: bridge: make sure to pull arp header in br_nf_forward_arp() - inetpeer: fix data-race in inet_putpeer / inet_putpeer - net: add a READ_ONCE() in skb_peek_tail() - net: icmp: fix data-race in cmp_global_allow() - hrtimer: Annotate lockless access to timer->state - spi: fsl: don't map irq during probe - tty/serial: atmel: fix out of range clock divider handling - pinctrl: baytrail:
[Bug 1850540] Re: multi-zone raid0 corruption
This bug was fixed in the package linux - 5.3.0-40.32 --- linux (5.3.0-40.32) eoan; urgency=medium * eoan/linux: 5.3.0-40.32 -proposed tracker (LP: #1861214) * No sof soundcard for 'ASoC: CODEC DAI intel-hdmi-hifi1 not registered' after modprobe sof (LP: #1860248) - ASoC: SOF: Intel: fix HDA codec driver probe with multiple controllers * ocfs2-tools is causing kernel panics in Ubuntu Focal (Ubuntu-5.4.0-9.12) (LP: #1852122) - ocfs2: fix the crash due to call ocfs2_get_dlm_debug once less * QAT drivers for C3XXX and C62X not included as modules (LP: #1845959) - [Config] CRYPTO_DEV_QAT_C3XXX=m, CRYPTO_DEV_QAT_C62X=m and CRYPTO_DEV_QAT_DH895xCC=m * Eoan update: upstream stable patchset 2020-01-24 (LP: #1860816) - scsi: lpfc: Fix discovery failures when target device connectivity bounces - scsi: mpt3sas: Fix clear pending bit in ioctl status - scsi: lpfc: Fix locking on mailbox command completion - Input: atmel_mxt_ts - disable IRQ across suspend - f2fs: fix to update time in lazytime mode - iommu: rockchip: Free domain on .domain_free - iommu/tegra-smmu: Fix page tables in > 4 GiB memory - dmaengine: xilinx_dma: Clear desc_pendingcount in xilinx_dma_reset - scsi: target: compare full CHAP_A Algorithm strings - scsi: lpfc: Fix SLI3 hba in loop mode not discovering devices - scsi: csiostor: Don't enable IRQs too early - scsi: hisi_sas: Replace in_softirq() check in hisi_sas_task_exec() - powerpc/pseries: Mark accumulate_stolen_time() as notrace - powerpc/pseries: Don't fail hash page table insert for bolted mapping - powerpc/tools: Don't quote $objdump in scripts - dma-debug: add a schedule point in debug_dma_dump_mappings() - leds: lm3692x: Handle failure to probe the regulator - clocksource/drivers/asm9260: Add a check for of_clk_get - clocksource/drivers/timer-of: Use unique device name instead of timer - powerpc/security/book3s64: Report L1TF status in sysfs - powerpc/book3s64/hash: Add cond_resched to avoid soft lockup warning - ext4: update direct I/O read lock pattern for IOCB_NOWAIT - ext4: iomap that extends beyond EOF should be marked dirty - jbd2: Fix statistics for the number of logged blocks - scsi: tracing: Fix handling of TRANSFER LENGTH == 0 for READ(6) and WRITE(6) - scsi: lpfc: Fix duplicate unreg_rpi error in port offline flow - f2fs: fix to update dir's i_pino during cross_rename - clk: qcom: Allow constant ratio freq tables for rcg - clk: clk-gpio: propagate rate change to parent - irqchip/irq-bcm7038-l1: Enable parent IRQ if necessary - irqchip: ingenic: Error out if IRQ domain creation failed - fs/quota: handle overflows of sysctl fs.quota.* and report as unsigned long - scsi: lpfc: fix: Coverity: lpfc_cmpl_els_rsp(): Null pointer dereferences - PCI: rpaphp: Fix up pointer to first drc-info entry - scsi: ufs: fix potential bug which ends in system hang - powerpc/pseries/cmm: Implement release() function for sysfs device - PCI: rpaphp: Don't rely on firmware feature to imply drc-info support - PCI: rpaphp: Annotate and correctly byte swap DRC properties - PCI: rpaphp: Correctly match ibm, my-drc-index to drc-name when using drc- info - powerpc/security: Fix wrong message when RFI Flush is disable - scsi: atari_scsi: sun3_scsi: Set sg_tablesize to 1 instead of SG_NONE - clk: pxa: fix one of the pxa RTC clocks - bcache: at least try to shrink 1 node in bch_mca_scan() - HID: quirks: Add quirk for HP MSU1465 PIXART OEM mouse - HID: logitech-hidpp: Silence intermittent get_battery_capacity errors - ARM: 8937/1: spectre-v2: remove Brahma-B53 from hardening - libnvdimm/btt: fix variable 'rc' set but not used - HID: Improve Windows Precision Touchpad detection. - HID: rmi: Check that the RMI_STARTED bit is set before unregistering the RMI transport device - watchdog: Fix the race between the release of watchdog_core_data and cdev - scsi: pm80xx: Fix for SATA device discovery - scsi: ufs: Fix error handing during hibern8 enter - scsi: scsi_debug: num_tgts must be >= 0 - scsi: NCR5380: Add disconnect_mask module parameter - scsi: iscsi: Don't send data to unbound connection - scsi: target: iscsi: Wait for all commands to finish before freeing a session - gpio: mpc8xxx: Don't overwrite default irq_set_type callback - apparmor: fix unsigned len comparison with less than zero - scripts/kallsyms: fix definitely-lost memory leak - powerpc: Don't add -mabi= flags when building with Clang - cdrom: respect device capabilities during opening action - perf script: Fix brstackinsn for AUXTRACE - perf regs: Make perf_reg_name() return "unknown" instead of NULL - s390/zcrypt: handle new reply code FILTERED_BY_HYPERVISOR - libfdt: define INT32_MAX and UINT32_MAX in libfdt_env.h -
[Bug 1850540] Re: multi-zone raid0 corruption
= linux/eoan verification = I created a multi-zone array on current eoan, then upgraded to the -proposed kernel: [4.021562] md/raid0:md0: !!! DEFAULTING TO ALTERNATE LAYOUT !!! [4.021563] md/raid0: Please set raid0.default_layout to 1 or 2 [4.021564] md/raid0: Read the following page for more information: [4.021564] md/raid0: https://wiki.ubuntu.com/Kernel/Raid0LayoutMigration I verified that the array is active. = linux/bionic verification = Similarly: [1.830003] md/raid0:md0: !!! DEFAULTING TO ALTERNATE LAYOUT !!! [1.835050] md/raid0: Please set raid0.default_layout to 1 or 2 [1.839513] md/raid0: Read the following page for more information: [1.844259] md/raid0: https://wiki.ubuntu.com/Kernel/Raid0LayoutMigration = linux/xenial verification = Similarly: [3.157653] md: raid0 personality registered for level 0 [3.170468] md/raid0:md0: !!! DEFAULTING TO ALTERNATE LAYOUT !!! [3.176180] md/raid0: Please set raid0.default_layout to 1 or 2 [3.181684] md/raid0: Read the following page for more information: [3.187394] md/raid0: https://wiki.ubuntu.com/Kernel/Raid0LayoutMigration ** Tags removed: verification-needed verification-needed-bionic verification-needed-disco verification-needed-eoan ** Tags added: verification-done verification-done-bionic verification-done-disco verification-done-eoan ** Tags removed: verification-needed-xenial ** Tags added: verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
** Tags removed: verification-done verification-done-bionic verification-done-disco verification-done-eoan ** Tags added: verification-needed verification-needed-bionic verification-needed-disco verification-needed-eoan ** Tags removed: block-proposed-bionic block-proposed-disco block- proposed-eoan -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
This bug was fixed in the package mdadm - 4.1~rc1-3~ubuntu18.04.4 --- mdadm (4.1~rc1-3~ubuntu18.04.4) bionic; urgency=medium * Introduce "broken" state for RAID0/Linear in mdadm (LP: #1847924) - d/p/lp1847924-Introduce-new-array-state-broken-for-raid0.patch * Disable patches from proposed version 4.1~rc1-3~ubuntu18.04.3 due to issues with kernel -- gpicc...@canonical.com (Guilherme G. Piccoli) Tue, 14 Jan 2020 16:10:59 -0300 ** Changed in: mdadm (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- xenial' to 'verification-done-xenial'. If the problem still exists, change the tag 'verification-needed-xenial' to 'verification-failed- xenial'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-xenial -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
** Changed in: linux (Ubuntu Bionic) Status: In Progress => Fix Committed ** Changed in: linux (Ubuntu Disco) Status: In Progress => Fix Committed ** Changed in: linux (Ubuntu Eoan) Status: In Progress => Fix Committed ** Changed in: linux (Ubuntu Xenial) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
** Changed in: linux (Ubuntu Trusty) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
The following patches sent on 2019/12/18 have been removed from the Eoan/Disco/Bionic kernels: https://lists.ubuntu.com/archives/kernel-team/2019-December/106461.html Therefore I'm setting the linux tasks back to 'In Progress'. ** Changed in: linux (Ubuntu Bionic) Status: Fix Committed => In Progress ** Changed in: linux (Ubuntu Disco) Status: Fix Committed => In Progress ** Changed in: linux (Ubuntu Eoan) Status: Fix Committed => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
** Changed in: linux (Ubuntu Bionic) Status: Confirmed => Fix Committed ** Changed in: linux (Ubuntu Disco) Status: Confirmed => Fix Committed ** Changed in: linux (Ubuntu Eoan) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
Adding the block-proposed-* tags as per comment #11. ** Tags removed: verification-needed verification-needed-bionic verification-needed-disco verification-needed-eoan ** Tags added: block-proposed-bionic block-proposed-disco block-proposed-eoan verification-done verification-done-bionic verification-done-disco verification-done-eoan -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
There is no plan to reapply the kernel side of these fixes ahead of 18.04.4. Introducing the mdadm side of that in 18.04.4 therefore would cause a regression in functionality: ubuntu@ip-172-30-0-208:~$ sudo mdadm --create /dev/md0 --run --metadata=default --level=0 --raid-devices=2 /dev/xvdb /dev/xvdc mdadm: /dev/xvdb appears to be part of a raid array: level=raid0 devices=2 ctime=Wed Dec 11 22:10:59 2019 mdadm: /dev/xvdc appears to be part of a raid array: level=raid0 devices=2 ctime=Wed Dec 11 22:10:59 2019 mdadm: ADD_NEW_DISK for /dev/xvdb failed: Invalid argument mdadm: Possibly your kernel doesn't support RAID0 layouts. mdadm: Either upgrade, or use --layout=dangerous Of course, at install time, upgrading the kernel isn't an option. So let's hold this SRU until after the point release. ** Description changed: Bug 1849682 tracks the temporarily revert of the fix for this issue, while this bug tracks the re-application of that fix once we have a full solution. [Impact] (cut & paste from https://marc.info/?l=linux-raid=157360088014027=2) An unintentional RAID0 layout change was introduced in the v3.14 kernel. This effectively means there are 2 different layouts Linux will use to write data to RAID0 arrays in the wild - the “pre-3.14” way and the “3.14 and later” way. Mixing these layouts by writing to an array while booted on these different kernel versions can lead to corruption. Note that this only impacts RAID0 arrays that include devices of different sizes. If your devices are all the same size, both layouts are equivalent, and your array is not at risk of corruption due to this issue. Unfortunately, the kernel cannot detect which layout was used for writes to pre-existing arrays, and therefore requires input from the administrator. This input can be provided via the kernel command line with the raid0.default_layout= parameter, or by setting the default_layout module parameter when loading the raid0 module. With a new enough version of mdadm (>= 4.2, or equivalent distro backports), you can set the layout version when assembling a stopped array. For example: mdadm --stop /dev/md0 mdadm --assemble -U layout-alternate /dev/md0 /dev/sda1 /dev/sda2 See the mdadm manpage for more details. Once set in this manner, the layout will be recorded in the array and will not need to be explicitly specified in the future. (The mdadm part of this SRU is for the above support ^) [Test Case] = mdadm = Confirm that a multi-zone raid0 created w/ older mdadm is able to be started on a fixed kernel by setting a layout. 1) Ex: w/ old kernel/mdadm: mdadm --create /dev/md0 --run --metadata=default \ --level=0 --raid-devices=2 /dev/vdb1 /dev/vdc1 2) Reboot onto fixed kernel & update mdadm 3) sudo mdadm --stop /dev/md0 && -sudo mdadm --assemble -U layout-alternate \ + sudo mdadm --assemble -U layout-alternate \ /dev/md0 /dev/vdb1 /dev/vdc1 4) Confirm that the array autostarts on reboot 5) Confirm that w/ new kernel & new mdadm, a user can create and start an array in a backwards-compatible fashion (i.e. w/o an explicit layout). 6) Verify that 'mdadm --detail /dev/md0' displays the layout = linux = Similar to above, but using kernel command line options. [Regression Risk] The kernel side of things will break starting pre-existing arrays. That's intentional. - Although I've done due-diligence to check for backwards compatibility - issues, the mdadm side may still present some. + The mdadm side will cause a regression in functionality where a user can + no longer create multi-zone raid0s on kernels that do not yet have the + raid0 layout patches. This is intentional, as such RAID arrays present a + corruption risk. ** Tags removed: verification-done verification-done-bionic verification-done-disco verification-done-eoan ** Tags added: verification-needed verification-needed-bionic verification-needed-disco verification-needed-eoan -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
= bionic verification = ubuntu@ip-172-30-0-117:~$ sudo mdadm --create /dev/md0 --run --metadata=default --level=0 --raid-devices=4 /dev/xvdb /dev/xvdc /dev/xvdd /dev/xvde mdadm: array /dev/md0 started. ubuntu@ip-172-30-0-117:~$ cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid0 xvde[3] xvdd[2] xvdc[1] xvdb[0] 29323264 blocks super 1.2 512k chunks unused devices: ## kernel & mdadm upgrade ubuntu@ip-172-30-0-117:~$ dmesg | grep raid [4.086107] md/raid0:md0: cannot assemble multi-zone RAID0 with default_layout setting [4.092253] md/raid0: please set raid0.default_layout to 1 or 2 [4.452725] raid6: avx2x4 gen() 24200 MB/s [4.500724] raid6: avx2x4 xor() 15657 MB/s [4.548725] raid6: avx2x2 gen() 21010 MB/s [4.596724] raid6: avx2x2 xor() 13248 MB/s [4.644724] raid6: avx2x1 gen() 18005 MB/s [4.692726] raid6: avx2x1 xor() 12606 MB/s [4.740726] raid6: sse2x4 gen() 13375 MB/s [4.788725] raid6: sse2x4 xor() 8309 MB/s [4.836730] raid6: sse2x2 gen() 11042 MB/s [4.884725] raid6: sse2x2 xor() 7264 MB/s [4.932730] raid6: sse2x1 gen() 9288 MB/s [4.980723] raid6: sse2x1 xor() 6578 MB/s [4.983827] raid6: using algorithm avx2x4 gen() 24200 MB/s [4.987535] raid6: xor() 15657 MB/s, rmw enabled [4.991018] raid6: using avx2x2 recovery algorithm ubuntu@ip-172-30-0-117:~$ cat /proc/mdstat Personalities : [raid0] [linear] [multipath] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : inactive xvdd[2] xvde[3] xvdb[0] xvdc[1] 29323264 blocks super 1.2 unused devices: ubuntu@ip-172-30-0-117:~$ sudo mdadm --stop /dev/md0 mdadm: stopped /dev/md0 ubuntu@ip-172-30-0-117:~$ sudo mdadm --assemble /dev/md0 -U layout-alternate /dev/xvdb /dev/xvdc /dev/xvdd /dev/xvde mdadm: /dev/md0 has been started with 4 drives. ubuntu@ip-172-30-0-117:~$ cat /proc/mdstat Personalities : [raid0] [linear] [multipath] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid0 xvdb[0] xvde[3] xvdd[2] xvdc[1] 29323264 blocks super 1.2 512k chunks unused devices: ## reboot ubuntu@ip-172-30-0-117:~$ dmesg | grep raid [3.793154] raid6: avx2x4 gen() 24292 MB/s [3.841155] raid6: avx2x4 xor() 15646 MB/s [3.889157] raid6: avx2x2 gen() 20570 MB/s [3.937155] raid6: avx2x2 xor() 13351 MB/s [3.985155] raid6: avx2x1 gen() 18190 MB/s [4.033154] raid6: avx2x1 xor() 12469 MB/s [4.081153] raid6: sse2x4 gen() 13399 MB/s [4.129153] raid6: sse2x4 xor() 8358 MB/s [4.177151] raid6: sse2x2 gen() 10984 MB/s [4.225157] raid6: sse2x2 xor() 7224 MB/s [4.273158] raid6: sse2x1 gen() 9335 MB/s [4.321157] raid6: sse2x1 xor() 6578 MB/s [4.323567] raid6: using algorithm avx2x4 gen() 24292 MB/s [4.326583] raid6: xor() 15646 MB/s, rmw enabled [4.329350] raid6: using avx2x2 recovery algorithm ubuntu@ip-172-30-0-117:~$ cat /proc/mdstat Personalities : [raid0] [linear] [multipath] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid0 xvde[3] xvdb[0] xvdc[1] xvdd[2] 29323264 blocks super 1.2 512k chunks unused devices: ubuntu@ip-172-30-0-117:~$ sudo mdadm --stop /dev/md0 mdadm: stopped /dev/md0 ubuntu@ip-172-30-0-117:~$ sudo mdadm --create /dev/md0 --run --metadata=default --level=0 --raid-devices=3 /dev/xvdb /dev/xvdd /dev/xvde mdadm: /dev/xvdb appears to be part of a raid array: level=raid0 devices=4 ctime=Fri Dec 6 22:20:04 2019 mdadm: /dev/xvdd appears to be part of a raid array: level=raid0 devices=4 ctime=Fri Dec 6 22:20:04 2019 mdadm: /dev/xvde appears to be part of a raid array: level=raid0 devices=4 ctime=Fri Dec 6 22:20:04 2019 mdadm: array /dev/md0 started. ubuntu@ip-172-30-0-117:~$ sudo mdadm --detail /dev/md0 | grep Layout Layout : original ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
** Tags removed: verification-needed-disco ** Tags added: verification-done-disco -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
= disco verification = ubuntu@ip-172-30-0-118:~$ sudo mdadm --create /dev/md0 --run --metadata=default --level=0 --raid-devices=2 /dev/xvdb /dev/xvdc mdadm: Fail create md0 when using /sys/module/md_mod/parameters/new_array mdadm: array /dev/md0 started. ubuntu@ip-172-30-0-118:~$ cat /proc/mdstat Personalities : [raid0] md0 : active raid0 xvdc[1] xvdb[0] 3141632 blocks super 1.2 512k chunks unused devices: ## kernel & mdadm upgrade ubuntu@ip-172-30-0-118:~$ dmesg | grep raid [2.419732] md: If you don't use raid, use raid=noautodetect [4.990204] md/raid0:md0: cannot assemble multi-zone RAID0 with default_layout setting [4.997283] md/raid0: please set raid0.default_layout to 1 or 2 ubuntu@ip-172-30-0-118:~$ sudo mdadm --stop /dev/md0 mdadm: stopped /dev/md0 ubuntu@ip-172-30-0-118:~$ sudo mdadm --assemble -U layout-original /dev/md0 /dev/xvdb /dev/xvdc mdadm: /dev/md0 has been started with 2 drives. ubuntu@ip-172-30-0-118:~$ cat /proc/mdstat Personalities : [raid0] md0 : active raid0 xvdb[0] xvdc[1] 3141632 blocks super 1.2 512k chunks unused devices: ## reboot ubuntu@ip-172-30-0-118:~$ dmesg | grep raid [2.545479] md: If you don't use raid, use raid=noautodetect ubuntu@ip-172-30-0-118:~$ cat /proc/mdstat Personalities : [raid0] md0 : active raid0 xvdb[0] xvdc[1] 3141632 blocks super 1.2 512k chunks unused devices: ubuntu@ip-172-30-0-118:~$ sudo mdadm --stop /dev/md0 mdadm: stopped /dev/md0 ubuntu@ip-172-30-0-118:~$ sudo mdadm --create /dev/md0 --run --metadata=default --level=0 --raid-devices=2 /dev/xvdc /dev/xvdb mdadm: /dev/xvdc appears to be part of a raid array: level=raid0 devices=2 ctime=Fri Dec 6 21:57:50 2019 mdadm: /dev/xvdb appears to be part of a raid array: level=raid0 devices=2 ctime=Fri Dec 6 21:57:50 2019 mdadm: array /dev/md0 started. ubuntu@ip-172-30-0-118:~$ sudo mdadm --detail /dev/md0 | grep Layout Layout : original -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
= eoan verification = ubuntu@ip-172-30-0-147:~$ sudo mdadm --create /dev/md0 --run --metadata=default --level=0 --raid-devices=2 /dev/xvdb /dev/xvdc mdadm: Fail create md0 when using /sys/module/md_mod/parameters/new_array mdadm: array /dev/md0 started. ubuntu@ip-172-30-0-147:~$ cat /proc/mdstat Personalities : [raid0] md0 : active raid0 xvdc[1] xvdb[0] 3141632 blocks super 1.2 512k chunks unused devices: # Upgraded mdadm & installed a 5.4 kernel ubuntu@ip-172-30-0-147:~$ dmesg | grep raid [3.009968] md: If you don't use raid, use raid=noautodetect [5.981265] md/raid0:md0: cannot assemble multi-zone RAID0 with default_layout setting [5.993787] md/raid0: please set raid0.default_layout to 1 or 2 ubuntu@ip-172-30-0-147:~$ sudo mdadm --stop /dev/md0 mdadm: stopped /dev/md0 ubuntu@ip-172-30-0-147:~$ sudo mdadm --assemble -U layout-alternate /dev/md0 /dev/xvdb /dev/xvdc mdadm: /dev/md0 has been started with 2 drives. ubuntu@ip-172-30-0-147:~$ cat /proc/mdstat Personalities : [raid0] md0 : active raid0 xvdb[0] xvdc[1] 3141632 blocks super 1.2 512k chunks unused devices: ## reboot ubuntu@ip-172-30-0-147:~$ dmesg | grep raid [2.440539] md: If you don't use raid, use raid=noautodetect ubuntu@ip-172-30-0-147:~$ cat /proc/mdstat Personalities : [raid0] md0 : active raid0 xvdb[0] xvdc[1] 3141632 blocks super 1.2 512k chunks unused devices: ubuntu@ip-172-30-0-147:~$ sudo mdadm --stop /dev/md0 mdadm: stopped /dev/md0 ubuntu@ip-172-30-0-147:~$ sudo mdadm --create /dev/md0 --run --metadata=default --level=0 --raid-devices=2 /dev/xvdc /dev/xvdb mdadm: /dev/xvdc appears to be part of a raid array: level=raid0 devices=2 ctime=Fri Dec 6 21:30:03 2019 mdadm: /dev/xvdb appears to be part of a raid array: level=raid0 devices=2 ctime=Fri Dec 6 21:30:03 2019 mdadm: array /dev/md0 started. ubuntu@ip-172-30-0-147:~$ sudo mdadm --stop /dev/md0 mdadm: stopped /dev/md0 ubuntu@ip-172-30-0-147:~$ sudo mdadm --create /dev/md0 --run --metadata=default --level=0 --raid-devices=2 /dev/xvdc /dev/xvdb --layout=original mdadm: /dev/xvdc appears to be part of a raid array: level=raid0 devices=2 ctime=Fri Dec 6 21:52:42 2019 mdadm: /dev/xvdb appears to be part of a raid array: level=raid0 devices=2 ctime=Fri Dec 6 21:52:42 2019 mdadm: array /dev/md0 started. ubuntu@ip-172-30-0-147:~$ sudo mdadm --detail /dev/md0 | grep Layout Layout : original ** Description changed: Bug 1849682 tracks the temporarily revert of the fix for this issue, while this bug tracks the re-application of that fix once we have a full solution. [Impact] (cut & paste from https://marc.info/?l=linux-raid=157360088014027=2) An unintentional RAID0 layout change was introduced in the v3.14 kernel. This effectively means there are 2 different layouts Linux will use to write data to RAID0 arrays in the wild - the “pre-3.14” way and the “3.14 and later” way. Mixing these layouts by writing to an array while booted on these different kernel versions can lead to corruption. Note that this only impacts RAID0 arrays that include devices of different sizes. If your devices are all the same size, both layouts are equivalent, and your array is not at risk of corruption due to this issue. Unfortunately, the kernel cannot detect which layout was used for writes to pre-existing arrays, and therefore requires input from the administrator. This input can be provided via the kernel command line with the raid0.default_layout= parameter, or by setting the default_layout module parameter when loading the raid0 module. With a new enough version of mdadm (>= 4.2, or equivalent distro backports), you can set the layout version when assembling a stopped array. For example: mdadm --stop /dev/md0 mdadm --assemble -U layout-alternate /dev/md0 /dev/sda1 /dev/sda2 See the mdadm manpage for more details. Once set in this manner, the layout will be recorded in the array and will not need to be explicitly specified in the future. (The mdadm part of this SRU is for the above support ^) [Test Case] = mdadm = Confirm that a multi-zone raid0 created w/ older mdadm is able to be started on a fixed kernel by setting a layout. 1) Ex: w/ old kernel/mdadm: - mdadm --create /dev/md0 --run --metadata=default \ - --level=0 --raid-devices=2 /dev/vdb1 /dev/vdc1 + mdadm --create /dev/md0 --run --metadata=default \ + --level=0 --raid-devices=2 /dev/vdb1 /dev/vdc1 2) Reboot onto fixed kernel & update mdadm - 3) sudo mdadm --assemble -U layout-alternate \ - /dev/md0 /dev/vdb1 /dev/vdc1 + 3) sudo mdadm --stop /dev/md0 && +sudo mdadm --assemble -U layout-alternate \ + /dev/md0 /dev/vdb1 /dev/vdc1 4) Confirm that the array autostarts on reboot 5) Confirm that w/ new kernel & new mdadm, a user can create and start an array in a backwards-compatible fashion (i.e. w/o an explicit layout). - 6) Verify
[Bug 1850540] Re: multi-zone raid0 corruption
Hello dann, or anyone else affected, Accepted mdadm into disco-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/mdadm/4.1-1ubuntu1.1 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-disco to verification-done-disco. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-disco. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: mdadm (Ubuntu Disco) Status: In Progress => Fix Committed ** Tags added: verification-needed-disco ** Changed in: mdadm (Ubuntu Bionic) Status: In Progress => Fix Committed ** Tags added: verification-needed-bionic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
Hello dann, or anyone else affected, Accepted mdadm into eoan-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/mdadm/4.1-2ubuntu3.1 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-eoan to verification-done-eoan. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-eoan. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: mdadm (Ubuntu Eoan) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-eoan -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
** Description changed: Bug 1849682 tracks the temporarily revert of the fix for this issue, while this bug tracks the re-application of that fix once we have a full solution. - Fix checklist: - [ ] Restore c84a1372df929 md/raid0: avoid RAID0 data corruption due to layout confusion. - [ ] Also apply these fixes: - 33f2c35a54dfd md: add feature flag MD_FEATURE_RAID0_LAYOUT - 3874d73e06c9b md/raid0: fix warning message for parameter default_layout - [ ] If upstream, include https://marc.info/?l=linux-raid=157239231220119=2 - [ ] mdadm update (see Comment #2) - [ ] Packaging work to detect/aide admin before reboot + [Impact] + (cut & paste from https://marc.info/?l=linux-raid=157360088014027=2) + An unintentional RAID0 layout change was introduced in the v3.14 kernel. This effectively means there are 2 different layouts Linux will use to write data to RAID0 arrays in the wild - the “pre-3.14” way and the “3.14 and later” way. Mixing these layouts by writing to an array while booted on these different kernel versions can lead to corruption. - Users of RAID0 arrays are susceptible to a corruption issue if: - - The members of the RAID array are not all the same size[*] - - Data has been written to the array while running kernels < 3.14 *and* >= 3.14. + Note that this only impacts RAID0 arrays that include devices of + different sizes. If your devices are all the same size, both layouts are + equivalent, and your array is not at risk of corruption due to this + issue. - This is because of an change in v3.14 that accidentally changed how data was written - as described in the upstream commit message: - https://github.com/torvalds/linux/commit/c84a1372df929033cb1a0441fb57bd3932f39ac9 + Unfortunately, the kernel cannot detect which layout was used for writes + to pre-existing arrays, and therefore requires input from the + administrator. This input can be provided via the kernel command line + with the raid0.default_layout= parameter, or by setting the + default_layout module parameter when loading the raid0 module. With a + new enough version of mdadm (>= 4.2, or equivalent distro backports), + you can set the layout version when assembling a stopped array. For + example: - That change has been applied to stable, but we reverted it to fix - 1849682 until we have a full solution ready. + mdadm --stop /dev/md0 + mdadm --assemble -U layout-alternate /dev/md0 /dev/sda1 /dev/sda2 + See the mdadm manpage for more details. Once set in this manner, the layout will be recorded in the array and will not need to be explicitly specified in the future. - To summarize, upstream is dealing with this by adding a versioned layout - in v5.4, and that is being backported to stable kernels - which is why - we're now seeing it. Layout version 1 is the pre-3.14 layout, version 2 - is post 3.14. Mixing version 1 & version 2 layouts can cause corruption. - However, until an mdadm exists that is able to set a layout in the - array, there's no way for the kernel to know which version(s) was used - to write the existing data. This undefined mode is considered "Version - 0", and the kernel will now refuse to start these arrays w/o user - intervention. + (The mdadm part of this SRU is for the above support ^) - The user experience is pretty awful here. A user upgrades to the next - SRU and all of a sudden their system stops at an (initramfs) prompt. A - clueful user can spot something like the following in dmesg: + [Test Case] + = mdadm = + Confirm that a multi-zone raid0 created w/ older mdadm is able to be started on a fixed kernel by setting a layout. + 1) Ex: w/ old kernel/mdadm: + mdadm --create /dev/md0 --run --metadata=default \ + --level=0 --raid-devices=2 /dev/vdb1 /dev/vdc1 + 2) Reboot onto fixed kernel & update mdadm + 3) sudo mdadm --assemble -U layout-alternate \ + /dev/md0 /dev/vdb1 /dev/vdc1 + 4) Confirm that the array autostarts on reboot + 5) Confirm that w/ new kernel & new mdadm, a user can create and start an array in a backwards-compatible fashion (i.e. w/o an explicit layout). + 6) Verify that 'mdadm --detail /dev/md0' displays the layout - Here's the message which , as you can see from the log in Comment #1, is - hidden in a ton of other messages: + = linux = + Similar to above, but using kernel command line options. - [ 72.720232] md/raid0:md0: cannot assemble multi-zone RAID0 with default_layout setting - [ 72.728149] md/raid0: please set raid.default_layout to 1 or 2 - [ 72.733979] md: pers->run() failed ... - mdadm: failed to start array /dev/md0: Unknown error 524 + [Regression Risk] + The kernel side of things will break starting pre-existing arrays. That's intentional. - What that is trying to say is that you should determine if your data - - specifically the data toward the end of your array - was most likely - written with a pre-3.14 or post-3.14 kernel. Based on that, reboot with - the kernel parameter raid0.default_layout=1 or
[Bug 1850540] Re: multi-zone raid0 corruption
This bug was fixed in the package mdadm - 4.1-4ubuntu1 --- mdadm (4.1-4ubuntu1) focal; urgency=medium [ dann frazier ] * Merge from Debian unstable. Remaining changes: - Ship finalrd hook. - Do not install mdadm-shutdown.service on Ubuntu. - Drop broken and unused init scripts in favor of native systemd units, which can cause failure to reconfigure mdadm package under certain confiment types. - Drop /etc/cron.d/mdadm and migrate to systemd mdcheck_start|continue timer units. - Drop /etc/cron.daily/mdadm and migrate to system mdmonitor-oneshot timer unit. - mdcheck_start.timer configures the mdcheck on a first sunday of the month, with a randomized start delay of up to 24h, and runs for at most 6h. mdcheck_continue.timer kicks off daily, with a randomized start delay of up to 12h, and continues mdcheck for at most 6h. - mdmonitor-oneshot.timer runs daily, with a randomized start delay of up to 24h. - One can use systemd drop-ins to change .timer units timings, set environmental variables to decrease/increase the length of checking, or start the checks by hand. Previously used checkarray is still available, albeit not used by timer units. - Above ensures that previous daily / monthly checks are performed, but are randomized, such that performance is not as impacted across a cluster of machines. * Honor the debconf daily autoscan setting in the systemd timer. [ Guilherme G. Piccoli ] * Introduce "broken" state for RAID0/Linear in mdadm (LP: #1847924) -- dann frazier Wed, 04 Dec 2019 07:05:07 -0700 ** Changed in: mdadm (Ubuntu Focal) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
** Changed in: mdadm (Debian) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
** Changed in: mdadm (Debian) Status: Unknown => New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
** Bug watch added: Debian Bug tracker #944676 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944676 ** Also affects: mdadm (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944676 Importance: Unknown Status: Unknown ** Also affects: ubuntu-release-notes Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
mdadm patches are under review upstream: https://marc.info/?l=linux-raid=157247979712647=2 ** Changed in: mdadm (Ubuntu Focal) Status: New => Confirmed ** Changed in: mdadm (Ubuntu Eoan) Status: New => Confirmed ** Changed in: mdadm (Ubuntu Disco) Status: New => Confirmed ** Changed in: mdadm (Ubuntu Bionic) Status: New => Confirmed ** Changed in: mdadm (Ubuntu Xenial) Status: New => Confirmed ** Changed in: mdadm (Ubuntu Trusty) Status: New => Confirmed ** Changed in: linux (Ubuntu Focal) Status: Incomplete => Confirmed ** Changed in: linux (Ubuntu Eoan) Status: Incomplete => Confirmed ** Changed in: linux (Ubuntu Disco) Status: Incomplete => Confirmed ** Changed in: linux (Ubuntu Bionic) Status: Incomplete => Confirmed ** Changed in: linux (Ubuntu Xenial) Status: Incomplete => Confirmed ** Changed in: linux (Ubuntu Trusty) Status: Incomplete => Confirmed ** Changed in: linux (Ubuntu Precise) Status: Incomplete => New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
** Description changed: Bug 1849682 tracks the temporarily revert of the fix for this issue, while this bug tracks the re-application of that fix once we have a full solution. + + Fix checklist: + [ ] Restore c84a1372df929 md/raid0: avoid RAID0 data corruption due to layout confusion. + [ ] Also apply these fixes: + 33f2c35a54dfd md: add feature flag MD_FEATURE_RAID0_LAYOUT + 3874d73e06c9b md/raid0: fix warning message for parameter default_layout + [ ] If upstream, include https://marc.info/?l=linux-raid=157239231220119=2 + [ ] mdadm update (see Comment #2) + [ ] Packaging work to detect/aide admin before reboot Users of RAID0 arrays are susceptible to a corruption issue if: - The members of the RAID array are not all the same size[*] - Data has been written to the array while running kernels < 3.14 *and* >= 3.14. This is because of an change in v3.14 that accidentally changed how data was written - as described in the upstream commit message: https://github.com/torvalds/linux/commit/c84a1372df929033cb1a0441fb57bd3932f39ac9 That change has been applied to stable, but we reverted it to fix 1849682 until we have a full solution ready. To summarize, upstream is dealing with this by adding a versioned layout in v5.4, and that is being backported to stable kernels - which is why we're now seeing it. Layout version 1 is the pre-3.14 layout, version 2 is post 3.14. Mixing version 1 & version 2 layouts can cause corruption. However, until an mdadm exists that is able to set a layout in the array, there's no way for the kernel to know which version(s) was used to write the existing data. This undefined mode is considered "Version 0", and the kernel will now refuse to start these arrays w/o user intervention. The user experience is pretty awful here. A user upgrades to the next SRU and all of a sudden their system stops at an (initramfs) prompt. A clueful user can spot something like the following in dmesg: Here's the message which , as you can see from the log in Comment #1, is hidden in a ton of other messages: [ 72.720232] md/raid0:md0: cannot assemble multi-zone RAID0 with default_layout setting [ 72.728149] md/raid0: please set raid.default_layout to 1 or 2 [ 72.733979] md: pers->run() failed ... mdadm: failed to start array /dev/md0: Unknown error 524 What that is trying to say is that you should determine if your data - specifically the data toward the end of your array - was most likely written with a pre-3.14 or post-3.14 kernel. Based on that, reboot with the kernel parameter raid0.default_layout=1 or raid0.default_layout=2 on the kernel command line. And note it should be *raid0.default_layout* not *raid.default_layout* as the message says - a fix for that message is now queued for stable: https://github.com/torvalds/linux/commit/3874d73e06c9b9dc15de0b7382fc223986d75571) IMHO, we should work with upstream to create a web page that clearly walks the user through this process, and update the error message to point to that page. I'd also like to see if we can detect this problem *before* the user reboots (debconf?) and help the user fix things. e.g. "We detected that you have RAID0 arrays that maybe susceptible to a corruption problem", guide the user to choosing a layout, and update the mdadm initramfs hook to poke the answer in via sysfs before starting the array on reboot. Note that it also seems like we should investigate backporting this to < 3.14 kernels. Imagine a user switching between the trusty HWE kernel and the GA kernel. References from users of other distros: https://blog.icod.de/2019/10/10/caution-kernel-5-3-4-and-raid0-default_layout/ https://www.linuxquestions.org/questions/linux-general-1/raid-arrays-not-assembling-4175662774/ [*] Which surprisingly is not the case reported in this bug - the user here had a raid0 of 8 identically-sized devices. I suspect there's a bug in the detection code somewhere. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
** Description changed: Bug 1849682 tracks the temporarily revert of the fix for this issue, while this bug tracks the re-application of that fix once we have a full solution. Users of RAID0 arrays are susceptible to a corruption issue if: - The members of the RAID array are not all the same size[*] - Data has been written to the array while running kernels < 3.14 *and* >= 3.14. This is because of an change in v3.14 that accidentally changed how data was written - as described in the upstream commit message: https://github.com/torvalds/linux/commit/c84a1372df929033cb1a0441fb57bd3932f39ac9 That change has been applied to stable, but we reverted it to fix 1849682 until we have a full solution ready. To summarize, upstream is dealing with this by adding a versioned layout in v5.4, and that is being backported to stable kernels - which is why we're now seeing it. Layout version 1 is the pre-3.14 layout, version 2 is post 3.14. Mixing version 1 & version 2 layouts can cause corruption. - However, unless a layout-version-aware kernel *created* the array, - there's no way for the kernel to know which version(s) was used to write - the existing data. This undefined mode is considered "Version 0", and - the kernel will now refuse to start these arrays w/o user intervention. + However, until an mdadm exists that is able to set a layout in the + array, there's no way for the kernel to know which version(s) was used + to write the existing data. This undefined mode is considered "Version + 0", and the kernel will now refuse to start these arrays w/o user + intervention. The user experience is pretty awful here. A user upgrades to the next SRU and all of a sudden their system stops at an (initramfs) prompt. A clueful user can spot something like the following in dmesg: Here's the message which , as you can see from the log in Comment #1, is hidden in a ton of other messages: [ 72.720232] md/raid0:md0: cannot assemble multi-zone RAID0 with default_layout setting [ 72.728149] md/raid0: please set raid.default_layout to 1 or 2 [ 72.733979] md: pers->run() failed ... mdadm: failed to start array /dev/md0: Unknown error 524 What that is trying to say is that you should determine if your data - specifically the data toward the end of your array - was most likely written with a pre-3.14 or post-3.14 kernel. Based on that, reboot with the kernel parameter raid0.default_layout=1 or raid0.default_layout=2 on the kernel command line. And note it should be *raid0.default_layout* not *raid.default_layout* as the message says - a fix for that message is now queued for stable: https://github.com/torvalds/linux/commit/3874d73e06c9b9dc15de0b7382fc223986d75571) IMHO, we should work with upstream to create a web page that clearly walks the user through this process, and update the error message to point to that page. I'd also like to see if we can detect this problem *before* the user reboots (debconf?) and help the user fix things. e.g. "We detected that you have RAID0 arrays that maybe susceptible to a corruption problem", guide the user to choosing a layout, and update the mdadm initramfs hook to poke the answer in via sysfs before starting the array on reboot. Note that it also seems like we should investigate backporting this to < 3.14 kernels. Imagine a user switching between the trusty HWE kernel and the GA kernel. References from users of other distros: https://blog.icod.de/2019/10/10/caution-kernel-5-3-4-and-raid0-default_layout/ https://www.linuxquestions.org/questions/linux-general-1/raid-arrays-not-assembling-4175662774/ [*] Which surprisingly is not the case reported in this bug - the user here had a raid0 of 8 identically-sized devices. I suspect there's a bug in the detection code somewhere. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1850540] Re: multi-zone raid0 corruption
I've nominated mdadm for this issue as well because it currently does not: 1) Let you create a new raid0 array w/o first setting a default_layout, which will regress behavior in installers, etc. 2) save the layout version in the raid config, so you need to set default_layout - or set individual array layouts via sysfs - on every boot 3) doesn't allow you to specify a layout when creating a raid0 (--layout is permitted for raid5, but not for raid0 yet) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850540 Title: multi-zone raid0 corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1850540/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
