[Bug 1078495] skelcd-control-openSUSE: missing swap settings
http://bugzilla.suse.com/show_bug.cgi?id=1078495
http://bugzilla.suse.com/show_bug.cgi?id=1078495#c17
--- Comment #17 from Ancor Gonzalez Sosa
If RAM is enough I think I'd sacrifice swap before turning off snapshots. If the system is really too low on RAM though then it needs to keep swap on of course. Does that make sense?
The amount of RAM is not a criterion right now when disabling volumes (or deactivating any of it's features like enlarging or snapshots). The proposal tries to make everything fit with the default options and, if that's not possible, if disables volumes (first its features and then the volume itself[1]) one by one following the disable_order. Swap is just another generic volume in that regard[2], so it gets disabled when it's its turn, without any consideration about the RAM size. We really need to make volumes generic and configurable via control.xml, ad-hoc logic for every volume was a dead end. It didn't fit many use cases like Kubic/CaaSP, SLE4SAAP, the KVM role, some product wanting to enlarge the root partition based on size (for kdump) and other half-dozen scenarios that were unhappy with the traditional desktop-centric logic. One obvious option to make the mechanism more flexible (that was somehow expected from the very beginning, just not introduced to keep the format as simple as possible) would be to have (in addition to disable_order) more specific attributes proposed_disable_order, snapshots_disable_order and adjust_by_ram_disable_order. With that you could have something like: If initial settings fail, try disabling '/home' If that fails, try deactivating 'adjust_by_ram' for swap If that fails, try deactivating 'snapshots' for root If that fails, fail (i.e. don't automatically propose to disable root or swap) While still having swap optional (i.e. possible to deactivate by the user in the UI). Not exactly what you asked, I know. What you asked would imply having a condition (the RAM size) to decide whether a particular volume (or one of its feature) must be disabled. Not sure how to make that while keeping the system understandable. Should that condition specified in the control file (ram_size_to_not_disable)? How long will it take for someone else to ask for another custom condition for another volume? [1] It disables what is possible, based on the xxx_configurable settings. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com