@kmously sorry to not coming back earlier to that I actually already did a verification some days ago when I setup a fresh LPAR with Eoan and having proposed enabled. Since the patch/backport disables thin provisioning it's a regression test what's needed to see if something else got accidentally harmed. For a different ticket I had to recompile a patched kernel (incl. headers, etc.) and everything worked fine and I didn't faced any issue. Today in my morning I setup a z/VM guest on top with Eoan, enabled proposed, and updated also there to kernel 5.3.0-40 and explicitly wrote file crossing track boundaries and everything was fine (like expected, since ECKD thin provisioning was not active - and can't be activated anymore with that kernel, since the code was revoked). Hence I successfully verified the Eoan proposed kernel (and with that adjusting the tags).
** Tags removed: verification-needed-eoan ** Tags added: verification-done-eoan -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1860535 Title: Disable ECKD Thin Provisioning to prevent data loss Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Invalid Status in linux source package in Eoan: Fix Committed Bug description: SRU Justification: ------------------ [Impact] * A severe problem with 'thin provisioning ECKD volumes', introduced with 19.10's kernel 5.3, was identified. * For enhanced space efficient (ese) volumes, errors may occur when accessing not formatted tracks. * In such a case the driver either formats the track on the fly for write requests or returns zero data for read requests. * But if a write request spans multiple tracks, the indication of an unformatted track can be in wc applied to all tracks. * Hence tracks containing data will be handled as empty tracks, resulting in zero data being returned on read, or overwriting existing data with zero on write. [Fix] * Backport: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860535/+attachment/5323313/+files/0001-s390 -dasd-disable-ese-support-due-to-possible-data-c.patch [Test Case] * An s390x LPAR with Eoan / kernel 5.3 and at least one 3390 DASD (ECKD) disk is needed ('discard' enabled, which is default). * Writing arbitrary files (but with known content, e.g. all '1's) to fill the disk up to a certain level * Since all 3390 DASDs (mod-3, 9, 27 or 54 ...) have 56,664 bytes per track, writing a file (again with simple but known content) with a size of a multiple of 56,664 bytes on a thin provisioned ECKD DASD device should provoke the error situation. * Check the files for any modifications (partially filled with '0', cut/truncated, deleted/zero length). [Regression Potential] * The regression potential is moderate since this is purely s390x specific, * limited to thin provisioned DASD disks on Eoan / kernel 5.3 * and just disables the broken feature and reverts things back to a DASD functionality that is known to work. [Other Info] * For 19.10 / Eoan no real fix will be provided, but a patch for disabling this feature completely (this bug/patch). * The broken functionality that got introduced in Eoan, got already partially removed due to problems on z/VM. * For 20.04 / Focal a proper fix is in the works that will be made available as backport to Focal's kernel 5.4. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1860535/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
