** Description changed: + [Impact] + * People creating manually datasets under the reserved namespace /USERDATA/ were considered good to clean up by ZSys and were removed. + * Even if this namespace shouldn’t be used by user, mitigate by preventing GC to collect and destroy them. + * Mark them differently to ZSys user datasets that were untagged so that those last ones are still considered for cleanup + * This is covered by dedicated use cases. + + [Test Case] + 1. zfs create rpool/USERDATA/foo + 2. Run zsysctl service GC + 3. Check that rpool/USERDATA/foo hasn’t been collected. + + [Regression Potential] + * The clean up was too extreme for those edge cases users. + * GC is a separate, timer-based process and don’t impact boot or other operations. + * The 30 existing tests on the GC didn’t regress and we now have some additional ones around those use case. + This was reported as https://github.com/ubuntu/zsys/issues/103. Don’t remove anything that is under /USERDATA/ if this wasn’t a fully zsys unlinked user state (with every other states unlinked as well)
** Description changed: [Impact] - * People creating manually datasets under the reserved namespace /USERDATA/ were considered good to clean up by ZSys and were removed. - * Even if this namespace shouldn’t be used by user, mitigate by preventing GC to collect and destroy them. - * Mark them differently to ZSys user datasets that were untagged so that those last ones are still considered for cleanup - * This is covered by dedicated use cases. + * People creating manually datasets under the reserved namespace /USERDATA/ were considered good to clean up by ZSys and were removed. + * Even if this namespace shouldn’t be used by user, mitigate by preventing GC to collect and destroy them. + * Mark them differently to ZSys user datasets that were untagged so that those last ones are still considered for cleanup + * This is covered by dedicated use cases. [Test Case] - 1. zfs create rpool/USERDATA/foo - 2. Run zsysctl service GC - 3. Check that rpool/USERDATA/foo hasn’t been collected. + 1. zfs create rpool/USERDATA/foo + 2. Run zsysctl service GC + 3. Check that rpool/USERDATA/foo hasn’t been collected. [Regression Potential] - * The clean up was too extreme for those edge cases users. - * GC is a separate, timer-based process and don’t impact boot or other operations. - * The 30 existing tests on the GC didn’t regress and we now have some additional ones around those use case. + * The clean up was too extreme for those edge cases users. + * GC is a separate, timer-based process and don’t impact boot or other operations. + * The 30 existing tests on the GC didn’t regress and we now have some additional ones around those use case. + + ----- This was reported as https://github.com/ubuntu/zsys/issues/103. Don’t remove anything that is under /USERDATA/ if this wasn’t a fully zsys unlinked user state (with every other states unlinked as well) ** Changed in: zsys (Ubuntu) Assignee: (unassigned) => Didier Roche (didrocks) ** Changed in: zsys (Ubuntu) Importance: Undecided => High ** Also affects: zsys (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: zsys (Ubuntu Focal) Assignee: (unassigned) => Didier Roche (didrocks) ** Changed in: zsys (Ubuntu Focal) Importance: Undecided => High -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to zsys in Ubuntu. https://bugs.launchpad.net/bugs/1881538 Title: Unmanaged datasets destroyed at boot time after import of zpool.cache Status in zsys package in Ubuntu: Fix Released Status in zsys source package in Focal: New Bug description: [Impact] * People creating manually datasets under the reserved namespace /USERDATA/ were considered good to clean up by ZSys and were removed. * Even if this namespace shouldn’t be used by user, mitigate by preventing GC to collect and destroy them. * Mark them differently to ZSys user datasets that were untagged so that those last ones are still considered for cleanup * This is covered by dedicated use cases. [Test Case] 1. zfs create rpool/USERDATA/foo 2. Run zsysctl service GC 3. Check that rpool/USERDATA/foo hasn’t been collected. [Regression Potential] * The clean up was too extreme for those edge cases users. * GC is a separate, timer-based process and don’t impact boot or other operations. * The 30 existing tests on the GC didn’t regress and we now have some additional ones around those use case. ----- This was reported as https://github.com/ubuntu/zsys/issues/103. Don’t remove anything that is under /USERDATA/ if this wasn’t a fully zsys unlinked user state (with every other states unlinked as well) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1881538/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
