[New: openFATE 320834] Create a /var/cache subvolume
Feature added by: Thorsten Kukuk (kukuk) Feature #320834, revision 1 Title: Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot and will be deleted only afterwards. This is a big problem if you regular update online, it will eat up your diskspace very fast. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Hannes Kühnemund (hkuehnemund) Feature #320834, revision 3 Title: Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot and will be deleted only afterwards. This is a big problem if you regular update online, it will eat up your diskspace very fast. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. + Discussion: + #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) + Just read the conversation on research and passed on to PrjMgr. -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Thorsten Kukuk (kukuk) Feature #320834, revision 4 Title: Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. - This means: all RPMs used for an update are part of the snapshot and - will be deleted only afterwards. This is a big problem if you regular - update online, it will eat up your diskspace very fast. + This means: all RPMs used for an update are part of the snapshot as + they will be only deleted after creating the snapshot. This is a big + problem if you regular update online, it will eat up your diskspace + very fast. The same is true for all other cached data, there is no real + sense in having them included into a snapshot, since they change very + fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Lukas Ocilka (locilka) Feature #320834, revision 6 Title: Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) + Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Jiri Srain (jsrain) Feature #320834, revision 7 - Title: Create a /var/cache subvolume + Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. + #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) + Updated yast2-storage is on its way to SP2:GA + (https://build.suse.de/request/show/114103). + Keeping open for now, since the release notes entry to document how to + create such subvolume in an installed system (without having any side + effects) is missing. -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Thorsten Kukuk (kukuk) Feature #320834, revision 8 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. + Release Notes: Move /var/cache into an own subvolume for snapshots and + rollback + Challenge: + /var/cache contains a lot of very volatile data. Due to this + volatility, the size a snapshot needs increases very fast for data, + which is not needed anymore. + To solve this, /var/cache should be moved into an own subvolume (if you + install with SLES12 SP2 or newer, this is done automatically during + installation). + The commands to do so are: + - mount <root device> -o subvol=@ /mnt (/mnt can be any unused mount + point) - btrfs subvol create /mnt/var/cache - mv /var/cache/* + /mnt/var/cache/ - umount /mnt - grep var.crash /etc/fstab | sed -e + 's|/var/crash|/var/cache|g' >> /etc/fstab - mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Thorsten Kukuk (kukuk) Feature #320834, revision 9 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. + #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) + I added some first, rough text for the release-notes. Release Notes: Move /var/cache into an own subvolume for snapshots and rollback Challenge: /var/cache contains a lot of very volatile data. Due to this volatility, the size a snapshot needs increases very fast for data, which is not needed anymore. + Solution: To solve this, /var/cache should be moved into an own subvolume (if you install with SLES12 SP2 or newer, this is done automatically during installation). The commands to do so are: - - mount <root device> -o subvol=@ /mnt (/mnt can be any unused mount - point) - btrfs subvol create /mnt/var/cache - mv /var/cache/* - /mnt/var/cache/ - umount /mnt - grep var.crash /etc/fstab | sed -e - 's|/var/crash|/var/cache|g' >> /etc/fstab - mount /var/cache + * - mount <root device> -o subvol=@ /mnt (/mnt can be any unused mount + point) + * - btrfs subvol create /mnt/var/cache + * - mv /var/cache/* /mnt/var/cache/ + * - umount /mnt + * - grep var.crash /etc/fstab | sed -e 's|/var/crash|/var/cache|g' >> + /etc/fstab + * - mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Frank Sundermeyer (fsundermeyer) Feature #320834, revision 10 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. + Documentation Impact: + snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. Release Notes: Move /var/cache into an own subvolume for snapshots and rollback Challenge: /var/cache contains a lot of very volatile data. Due to this volatility, the size a snapshot needs increases very fast for data, which is not needed anymore. Solution: To solve this, /var/cache should be moved into an own subvolume (if you install with SLES12 SP2 or newer, this is done automatically during installation). The commands to do so are: * - mount <root device> -o subvol=@ /mnt (/mnt can be any unused mount point) * - btrfs subvol create /mnt/var/cache * - mv /var/cache/* /mnt/var/cache/ * - umount /mnt * - grep var.crash /etc/fstab | sed -e 's|/var/crash|/var/cache|g' >> /etc/fstab * - mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Stefan Brüns (StefanBruens) Feature #320834, revision 11 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. + #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) + on openSUSE, / is not created as subvolume @ (at least it was not with + 13.2). + Documentation how to mv /var/cache in this case would be nice Release Notes: Move /var/cache into an own subvolume for snapshots and rollback Challenge: /var/cache contains a lot of very volatile data. Due to this volatility, the size a snapshot needs increases very fast for data, which is not needed anymore. Solution: To solve this, /var/cache should be moved into an own subvolume (if you install with SLES12 SP2 or newer, this is done automatically during installation). The commands to do so are: * - mount <root device> -o subvol=@ /mnt (/mnt can be any unused mount point) * - btrfs subvol create /mnt/var/cache * - mv /var/cache/* /mnt/var/cache/ * - umount /mnt * - grep var.crash /etc/fstab | sed -e 's|/var/crash|/var/cache|g' >> /etc/fstab * - mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Stefan Hundhammer (shundhammer) Feature #320834, revision 12 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice Release Notes: Move /var/cache into an own subvolume for snapshots and rollback Challenge: /var/cache contains a lot of very volatile data. Due to this volatility, the size a snapshot needs increases very fast for data, which is not needed anymore. Solution: - To solve this, /var/cache should be moved into an own subvolume (if you - install with SLES12 SP2 or newer, this is done automatically during - installation). - The commands to do so are: - * - mount <root device> -o subvol=@ /mnt (/mnt can be any unused mount - point) - * - btrfs subvol create /mnt/var/cache - * - mv /var/cache/* /mnt/var/cache/ - * - umount /mnt - * - grep var.crash /etc/fstab | sed -e 's|/var/crash|/var/cache|g' >> - /etc/fstab - * - mount /var/cache + To solve this, /var/cache should be moved into a separate subvolume. If + you install with SLES12 SP2 or newer, this is done automatically during + installation. For existing root file systems, do these steps manually: + - Explicitly mount the root file system's toplevel subvolume to another + mount point (/mnt in this example): - For SLE 12, that toplevel + subvolume is named "@": mount <root device> -o subvol=@ /mnt - btrfs + subvol create /mnt/var/cache - mv /var/cache/* /mnt/var/cache/ - umount + /mnt - Add an entry to /etc/fstab for the new /var/cache subvolume. - + grep var.crash /etc/fstab | sed -e 's|/var/crash|/var/cache|g' >> + /etc/fstab - mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Stefan Hundhammer (shundhammer) Feature #320834, revision 14 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice Release Notes: Move /var/cache into an own subvolume for snapshots and rollback Challenge: - /var/cache contains a lot of very volatile data. Due to this - volatility, the size a snapshot needs increases very fast for data, - which is not needed anymore. + /var/cache contains a lot of very volatile data, like the zypper cache + with RPM packages in a lot of different versions for each update. Due + to this volatility, the size a snapshot needs increases very fast for + data, which is not needed anymore. Solution: To solve this, /var/cache should be moved into a separate subvolume. If you install with SLES12 SP2 or newer, this is done automatically during installation. For existing root file systems, do these steps manually: - - Explicitly mount the root file system's toplevel subvolume to another - mount point (/mnt in this example): - For SLE 12, that toplevel - subvolume is named "@": mount <root device> -o subvol=@ /mnt - btrfs - subvol create /mnt/var/cache - mv /var/cache/* /mnt/var/cache/ - umount - /mnt - Add an entry to /etc/fstab for the new /var/cache subvolume. - - grep var.crash /etc/fstab | sed -e 's|/var/crash|/var/cache|g' >> - /etc/fstab - mount /var/cache + - Explicitly mount the root file system's toplevel subvolume to a + temporary mount point (using /mnt in this description). <root_device> + is the device name of the root file system (/dev/sda2, /dev/sda3 etc.) + - For SLE 12 and recent Tumbleweed installations (it depends on when + the root file system was created!), that toplevel subvolume is named + "@": mount <root_device> -o subvol=@ /mnt + - For openSUSE 13.2 and older Tumbleweed installations, this does not + have a name, so you will have to use the subvolume ID. This ID is + always 5: + mount <root_device> -o subvolid=5 /mnt + - Create a new subvolume: + btrfs subvol create /mnt/var/cache + - Move all files and directories from the root file system's /var/cache + to the new subvolume: + mv /var/cache/* /mnt/var/cache/ + - Unmount the subvolume from the temporary mount point: + umount /mnt + - Add an entry to /etc/fstab for the new /var/cache subvolume. Use an + existing subvolume as a template to copy from. Make sure to leave the + UUID untouched (this is the root file systems's UUID) and change the + subvolume name and its mount point consistently to /var/cache. + - Mount the new subvolume as specified in /etc/fstab: + mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Stefan Hundhammer (shundhammer) Feature #320834, revision 15 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice Release Notes: Move /var/cache into an own subvolume for snapshots and rollback Challenge: /var/cache contains a lot of very volatile data, like the zypper cache with RPM packages in a lot of different versions for each update. Due to this volatility, the size a snapshot needs increases very fast for data, which is not needed anymore. Solution: To solve this, /var/cache should be moved into a separate subvolume. If you install with SLES12 SP2 or newer, this is done automatically during installation. For existing root file systems, do these steps manually: - Explicitly mount the root file system's toplevel subvolume to a temporary mount point (using /mnt in this description). <root_device> is the device name of the root file system (/dev/sda2, /dev/sda3 etc.) - For SLE 12 and recent Tumbleweed installations (it depends on when the root file system was created!), that toplevel subvolume is named "@": mount <root_device> -o subvol=@ /mnt - For openSUSE 13.2 and older Tumbleweed installations, this does not - have a name, so you will have to use the subvolume ID. This ID is - always 5: + have a name, so you have to use the subvolume ID. This ID is always 5: mount <root_device> -o subvolid=5 /mnt - Create a new subvolume: btrfs subvol create /mnt/var/cache - Move all files and directories from the root file system's /var/cache to the new subvolume: mv /var/cache/* /mnt/var/cache/ - Unmount the subvolume from the temporary mount point: umount /mnt - Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. Make sure to leave the UUID untouched (this is the root file systems's UUID) and change the subvolume name and its mount point consistently to /var/cache. - Mount the new subvolume as specified in /etc/fstab: mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Stefan Hundhammer (shundhammer) Feature #320834, revision 16 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice Release Notes: Move /var/cache into an own subvolume for snapshots and rollback Challenge: /var/cache contains a lot of very volatile data, like the zypper cache with RPM packages in a lot of different versions for each update. Due to this volatility, the size a snapshot needs increases very fast for - data, which is not needed anymore. + data that are mostly redundant. Solution: To solve this, /var/cache should be moved into a separate subvolume. If you install with SLES12 SP2 or newer, this is done automatically during installation. For existing root file systems, do these steps manually: - Explicitly mount the root file system's toplevel subvolume to a temporary mount point (using /mnt in this description). <root_device> is the device name of the root file system (/dev/sda2, /dev/sda3 etc.) - For SLE 12 and recent Tumbleweed installations (it depends on when the root file system was created!), that toplevel subvolume is named "@": mount <root_device> -o subvol=@ /mnt - For openSUSE 13.2 and older Tumbleweed installations, this does not have a name, so you have to use the subvolume ID. This ID is always 5: mount <root_device> -o subvolid=5 /mnt - Create a new subvolume: btrfs subvol create /mnt/var/cache - Move all files and directories from the root file system's /var/cache to the new subvolume: mv /var/cache/* /mnt/var/cache/ - Unmount the subvolume from the temporary mount point: umount /mnt - Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. Make sure to leave the UUID untouched (this is the root file systems's UUID) and change the subvolume name and its mount point consistently to /var/cache. - Mount the new subvolume as specified in /etc/fstab: mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Stefan Hundhammer (shundhammer) Feature #320834, revision 17 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice Release Notes: Move /var/cache into an own subvolume for snapshots and rollback Challenge: /var/cache contains a lot of very volatile data, like the zypper cache with RPM packages in a lot of different versions for each update. Due to this volatility, the size a snapshot needs increases very fast for data that are mostly redundant. Solution: To solve this, /var/cache should be moved into a separate subvolume. If you install with SLES12 SP2 or newer, this is done automatically during installation. For existing root file systems, do these steps manually: - - Explicitly mount the root file system's toplevel subvolume to a - temporary mount point (using /mnt in this description). <root_device> - is the device name of the root file system (/dev/sda2, /dev/sda3 etc.) - - For SLE 12 and recent Tumbleweed installations (it depends on when - the root file system was created!), that toplevel subvolume is named - "@": mount <root_device> -o subvol=@ /mnt - - For openSUSE 13.2 and older Tumbleweed installations, this does not - have a name, so you have to use the subvolume ID. This ID is always 5: + - Identify the parent subvolume of all the other subvolumes. For SLE 12 + and recent Tumbleweed installations, this is a subvolume named "@". For + openSUSE 13.2 and older Tumbleweed installations, this it the unnamed + toplevel subvolume with ID 5. Check if you have a '@' subvolume: + btrfs subvolume list / | grep '@' + If the output of this command is empty, you don't have a subvolume + named '@'. In that case, use the subvolume with ID 5. + - Mount that subvolume to a temporary mount point (using /mnt in this + description). <root_device> is the device name of the root file system + (/dev/sda2, /dev/sda3 etc.) + - If you have a '@' subvolume, mount it: + mount <root_device> -o subvol=@ /mnt + - If you don't have a '@' subvolume (and only then!), mount subvolume + ID 5 instead: mount <root_device> -o subvolid=5 /mnt - - Create a new subvolume: + - In either case, create a new subvolume: btrfs subvol create /mnt/var/cache - Move all files and directories from the root file system's /var/cache to the new subvolume: mv /var/cache/* /mnt/var/cache/ - Unmount the subvolume from the temporary mount point: umount /mnt - Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. Make sure to leave the UUID untouched (this is the root file systems's UUID) and change the subvolume name and its mount point consistently to /var/cache. - Mount the new subvolume as specified in /etc/fstab: mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Stefan Hundhammer (shundhammer) Feature #320834, revision 18 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice + #5: Stefan Hundhammer (shundhammer) (2016-05-18 17:18:48) (reply to + #4) + Thanks for the hint, added that case to the release notes section. Release Notes: Move /var/cache into an own subvolume for snapshots and rollback Challenge: /var/cache contains a lot of very volatile data, like the zypper cache with RPM packages in a lot of different versions for each update. Due to this volatility, the size a snapshot needs increases very fast for data that are mostly redundant. Solution: To solve this, /var/cache should be moved into a separate subvolume. If you install with SLES12 SP2 or newer, this is done automatically during installation. For existing root file systems, do these steps manually: - Identify the parent subvolume of all the other subvolumes. For SLE 12 and recent Tumbleweed installations, this is a subvolume named "@". For openSUSE 13.2 and older Tumbleweed installations, this it the unnamed toplevel subvolume with ID 5. Check if you have a '@' subvolume: btrfs subvolume list / | grep '@' If the output of this command is empty, you don't have a subvolume named '@'. In that case, use the subvolume with ID 5. - Mount that subvolume to a temporary mount point (using /mnt in this description). <root_device> is the device name of the root file system (/dev/sda2, /dev/sda3 etc.) - If you have a '@' subvolume, mount it: mount <root_device> -o subvol=@ /mnt - If you don't have a '@' subvolume (and only then!), mount subvolume ID 5 instead: mount <root_device> -o subvolid=5 /mnt - In either case, create a new subvolume: btrfs subvol create /mnt/var/cache - Move all files and directories from the root file system's /var/cache to the new subvolume: mv /var/cache/* /mnt/var/cache/ - Unmount the subvolume from the temporary mount point: umount /mnt - Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. Make sure to leave the UUID untouched (this is the root file systems's UUID) and change the subvolume name and its mount point consistently to /var/cache. - Mount the new subvolume as specified in /etc/fstab: mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Stefan Hundhammer (shundhammer) Feature #320834, revision 19 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice #5: Stefan Hundhammer (shundhammer) (2016-05-18 17:18:48) (reply to #4) Thanks for the hint, added that case to the release notes section. + #6: Stefan Hundhammer (shundhammer) (2016-05-18 17:22:21) + Doc team please note that the release notes snippet is available in + prettier format here: + https://w3.suse.de/~shundhammer/release-notes-var-cache-subvol.txt Release Notes: Move /var/cache into an own subvolume for snapshots and rollback Challenge: /var/cache contains a lot of very volatile data, like the zypper cache with RPM packages in a lot of different versions for each update. Due to this volatility, the size a snapshot needs increases very fast for data that are mostly redundant. Solution: To solve this, /var/cache should be moved into a separate subvolume. If you install with SLES12 SP2 or newer, this is done automatically during installation. For existing root file systems, do these steps manually: - Identify the parent subvolume of all the other subvolumes. For SLE 12 and recent Tumbleweed installations, this is a subvolume named "@". For openSUSE 13.2 and older Tumbleweed installations, this it the unnamed toplevel subvolume with ID 5. Check if you have a '@' subvolume: btrfs subvolume list / | grep '@' If the output of this command is empty, you don't have a subvolume named '@'. In that case, use the subvolume with ID 5. - Mount that subvolume to a temporary mount point (using /mnt in this description). <root_device> is the device name of the root file system (/dev/sda2, /dev/sda3 etc.) - If you have a '@' subvolume, mount it: mount <root_device> -o subvol=@ /mnt - If you don't have a '@' subvolume (and only then!), mount subvolume ID 5 instead: mount <root_device> -o subvolid=5 /mnt - In either case, create a new subvolume: btrfs subvol create /mnt/var/cache - Move all files and directories from the root file system's /var/cache to the new subvolume: mv /var/cache/* /mnt/var/cache/ - Unmount the subvolume from the temporary mount point: umount /mnt - Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. Make sure to leave the UUID untouched (this is the root file systems's UUID) and change the subvolume name and its mount point consistently to /var/cache. - Mount the new subvolume as specified in /etc/fstab: mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Stefan Hundhammer (shundhammer) Feature #320834, revision 20 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice #5: Stefan Hundhammer (shundhammer) (2016-05-18 17:18:48) (reply to #4) Thanks for the hint, added that case to the release notes section. #6: Stefan Hundhammer (shundhammer) (2016-05-18 17:22:21) Doc team please note that the release notes snippet is available in prettier format here: https://w3.suse.de/~shundhammer/release-notes-var-cache-subvol.txt Release Notes: Move /var/cache into an own subvolume for snapshots and rollback Challenge: /var/cache contains a lot of very volatile data, like the zypper cache with RPM packages in a lot of different versions for each update. Due to this volatility, the size a snapshot needs increases very fast for data that are mostly redundant. Solution: To solve this, /var/cache should be moved into a separate subvolume. If you install with SLES12 SP2 or newer, this is done automatically during installation. For existing root file systems, do these steps manually: + - Find out the device name (/dev/sda2, /dev/sda3 etc.) of the root file + system: df / - Identify the parent subvolume of all the other subvolumes. For SLE 12 and recent Tumbleweed installations, this is a subvolume named "@". For openSUSE 13.2 and older Tumbleweed installations, this it the unnamed toplevel subvolume with ID 5. Check if you have a '@' subvolume: btrfs subvolume list / | grep '@' If the output of this command is empty, you don't have a subvolume named '@'. In that case, use the subvolume with ID 5. - - Mount that subvolume to a temporary mount point (using /mnt in this - description). <root_device> is the device name of the root file system - (/dev/sda2, /dev/sda3 etc.) - - If you have a '@' subvolume, mount it: + - If you have a '@' subvolume, mount that subvolume to a temporary + mount point (using /mnt in this description): mount <root_device> -o subvol=@ /mnt - If you don't have a '@' subvolume (and only then!), mount subvolume ID 5 instead: mount <root_device> -o subvolid=5 /mnt - In either case, create a new subvolume: btrfs subvol create /mnt/var/cache - Move all files and directories from the root file system's /var/cache to the new subvolume: mv /var/cache/* /mnt/var/cache/ - Unmount the subvolume from the temporary mount point: umount /mnt - Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. Make sure to leave the UUID untouched (this is the root file systems's UUID) and change the subvolume name and its mount point consistently to /var/cache. - Mount the new subvolume as specified in /etc/fstab: mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Jiri Srain (jsrain) Feature #320834, revision 21 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice #5: Stefan Hundhammer (shundhammer) (2016-05-18 17:18:48) (reply to #4) Thanks for the hint, added that case to the release notes section. + #7: Jiri Srain (jsrain) (2016-05-19 08:13:32) (reply to #5) + The RN entry (as well as this Fate) is for SLES - we should IMO leave + openSUSE out of the release notes completely and possibly create a + separate RN entry (separate Fate?) for openSUSE. + Alternatively, would it make sense to leave out the specific version + completely? After all, I would not be surprised if upgrades from latest + SLE11 SPs (direct or indirect) would behave the same as 13.2... #6: Stefan Hundhammer (shundhammer) (2016-05-18 17:22:21) Doc team please note that the release notes snippet is available in prettier format here: https://w3.suse.de/~shundhammer/release-notes-var-cache-subvol.txt Release Notes: Move /var/cache into an own subvolume for snapshots and rollback Challenge: /var/cache contains a lot of very volatile data, like the zypper cache with RPM packages in a lot of different versions for each update. Due to this volatility, the size a snapshot needs increases very fast for data that are mostly redundant. Solution: To solve this, /var/cache should be moved into a separate subvolume. If you install with SLES12 SP2 or newer, this is done automatically during installation. For existing root file systems, do these steps manually: - Find out the device name (/dev/sda2, /dev/sda3 etc.) of the root file system: df / - Identify the parent subvolume of all the other subvolumes. For SLE 12 and recent Tumbleweed installations, this is a subvolume named "@". For openSUSE 13.2 and older Tumbleweed installations, this it the unnamed toplevel subvolume with ID 5. Check if you have a '@' subvolume: btrfs subvolume list / | grep '@' If the output of this command is empty, you don't have a subvolume named '@'. In that case, use the subvolume with ID 5. - If you have a '@' subvolume, mount that subvolume to a temporary mount point (using /mnt in this description): mount <root_device> -o subvol=@ /mnt - If you don't have a '@' subvolume (and only then!), mount subvolume ID 5 instead: mount <root_device> -o subvolid=5 /mnt - In either case, create a new subvolume: btrfs subvol create /mnt/var/cache - Move all files and directories from the root file system's /var/cache to the new subvolume: mv /var/cache/* /mnt/var/cache/ - Unmount the subvolume from the temporary mount point: umount /mnt - Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. Make sure to leave the UUID untouched (this is the root file systems's UUID) and change the subvolume name and its mount point consistently to /var/cache. - Mount the new subvolume as specified in /etc/fstab: mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Thorsten Kukuk (kukuk) Feature #320834, revision 22 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice #5: Stefan Hundhammer (shundhammer) (2016-05-18 17:18:48) (reply to #4) Thanks for the hint, added that case to the release notes section. #7: Jiri Srain (jsrain) (2016-05-19 08:13:32) (reply to #5) The RN entry (as well as this Fate) is for SLES - we should IMO leave openSUSE out of the release notes completely and possibly create a separate RN entry (separate Fate?) for openSUSE. Alternatively, would it make sense to leave out the specific version completely? After all, I would not be surprised if upgrades from latest SLE11 SPs (direct or indirect) would behave the same as 13.2... + #8: Thorsten Kukuk (kukuk) (2016-05-19 09:06:25) (reply to #7) + Differentiating this between openSUSE and SLES is a good idea, since no + openSUSE user will read the SLES release notes. + Removing the version numbers is bad, since this are the important + information. And snapshot/rollback does not work if you are coming from + SLES11, since SLES11 has /boot on an extra partition. So SLES12 only is + correct. #6: Stefan Hundhammer (shundhammer) (2016-05-18 17:22:21) Doc team please note that the release notes snippet is available in prettier format here: https://w3.suse.de/~shundhammer/release-notes-var-cache-subvol.txt Release Notes: Move /var/cache into an own subvolume for snapshots and rollback Challenge: /var/cache contains a lot of very volatile data, like the zypper cache with RPM packages in a lot of different versions for each update. Due to this volatility, the size a snapshot needs increases very fast for data that are mostly redundant. Solution: To solve this, /var/cache should be moved into a separate subvolume. If you install with SLES12 SP2 or newer, this is done automatically during installation. For existing root file systems, do these steps manually: - Find out the device name (/dev/sda2, /dev/sda3 etc.) of the root file system: df / - Identify the parent subvolume of all the other subvolumes. For SLE 12 and recent Tumbleweed installations, this is a subvolume named "@". For openSUSE 13.2 and older Tumbleweed installations, this it the unnamed toplevel subvolume with ID 5. Check if you have a '@' subvolume: btrfs subvolume list / | grep '@' If the output of this command is empty, you don't have a subvolume named '@'. In that case, use the subvolume with ID 5. - If you have a '@' subvolume, mount that subvolume to a temporary mount point (using /mnt in this description): mount <root_device> -o subvol=@ /mnt - If you don't have a '@' subvolume (and only then!), mount subvolume ID 5 instead: mount <root_device> -o subvolid=5 /mnt - In either case, create a new subvolume: btrfs subvol create /mnt/var/cache - Move all files and directories from the root file system's /var/cache to the new subvolume: mv /var/cache/* /mnt/var/cache/ - Unmount the subvolume from the temporary mount point: umount /mnt - Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. Make sure to leave the UUID untouched (this is the root file systems's UUID) and change the subvolume name and its mount point consistently to /var/cache. - Mount the new subvolume as specified in /etc/fstab: mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Jiri Srain (jsrain) Feature #320834, revision 23 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice #5: Stefan Hundhammer (shundhammer) (2016-05-18 17:18:48) (reply to #4) Thanks for the hint, added that case to the release notes section. #7: Jiri Srain (jsrain) (2016-05-19 08:13:32) (reply to #5) The RN entry (as well as this Fate) is for SLES - we should IMO leave openSUSE out of the release notes completely and possibly create a separate RN entry (separate Fate?) for openSUSE. Alternatively, would it make sense to leave out the specific version completely? After all, I would not be surprised if upgrades from latest SLE11 SPs (direct or indirect) would behave the same as 13.2... #8: Thorsten Kukuk (kukuk) (2016-05-19 09:06:25) (reply to #7) Differentiating this between openSUSE and SLES is a good idea, since no openSUSE user will read the SLES release notes. Removing the version numbers is bad, since this are the important information. And snapshot/rollback does not work if you are coming from SLES11, since SLES11 has /boot on an extra partition. So SLES12 only is correct. + #9: Jiri Srain (jsrain) (2016-05-19 10:11:11) (reply to #8) + Not sure I got yoru comment right, my main point was: This feature is + for SLES only (Fate-wise); how will the text end up in openSUSE RN? And + how is openSUSE-specific part relevant for SLES customers if it appears + in their RN? Wouldn't it make more sense to have two separate RN + texts? #6: Stefan Hundhammer (shundhammer) (2016-05-18 17:22:21) Doc team please note that the release notes snippet is available in prettier format here: https://w3.suse.de/~shundhammer/release-notes-var-cache-subvol.txt Release Notes: Move /var/cache into an own subvolume for snapshots and rollback Challenge: /var/cache contains a lot of very volatile data, like the zypper cache with RPM packages in a lot of different versions for each update. Due to this volatility, the size a snapshot needs increases very fast for data that are mostly redundant. Solution: To solve this, /var/cache should be moved into a separate subvolume. If you install with SLES12 SP2 or newer, this is done automatically during installation. For existing root file systems, do these steps manually: - Find out the device name (/dev/sda2, /dev/sda3 etc.) of the root file system: df / - Identify the parent subvolume of all the other subvolumes. For SLE 12 and recent Tumbleweed installations, this is a subvolume named "@". For openSUSE 13.2 and older Tumbleweed installations, this it the unnamed toplevel subvolume with ID 5. Check if you have a '@' subvolume: btrfs subvolume list / | grep '@' If the output of this command is empty, you don't have a subvolume named '@'. In that case, use the subvolume with ID 5. - If you have a '@' subvolume, mount that subvolume to a temporary mount point (using /mnt in this description): mount <root_device> -o subvol=@ /mnt - If you don't have a '@' subvolume (and only then!), mount subvolume ID 5 instead: mount <root_device> -o subvolid=5 /mnt - In either case, create a new subvolume: btrfs subvol create /mnt/var/cache - Move all files and directories from the root file system's /var/cache to the new subvolume: mv /var/cache/* /mnt/var/cache/ - Unmount the subvolume from the temporary mount point: umount /mnt - Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. Make sure to leave the UUID untouched (this is the root file systems's UUID) and change the subvolume name and its mount point consistently to /var/cache. - Mount the new subvolume as specified in /etc/fstab: mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Jiri Srain (jsrain) Feature #320834, revision 24 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice #5: Stefan Hundhammer (shundhammer) (2016-05-18 17:18:48) (reply to #4) Thanks for the hint, added that case to the release notes section. #7: Jiri Srain (jsrain) (2016-05-19 08:13:32) (reply to #5) The RN entry (as well as this Fate) is for SLES - we should IMO leave openSUSE out of the release notes completely and possibly create a separate RN entry (separate Fate?) for openSUSE. Alternatively, would it make sense to leave out the specific version completely? After all, I would not be surprised if upgrades from latest SLE11 SPs (direct or indirect) would behave the same as 13.2... #8: Thorsten Kukuk (kukuk) (2016-05-19 09:06:25) (reply to #7) Differentiating this between openSUSE and SLES is a good idea, since no openSUSE user will read the SLES release notes. Removing the version numbers is bad, since this are the important information. And snapshot/rollback does not work if you are coming from SLES11, since SLES11 has /boot on an extra partition. So SLES12 only is correct. #9: Jiri Srain (jsrain) (2016-05-19 10:11:11) (reply to #8) Not sure I got yoru comment right, my main point was: This feature is for SLES only (Fate-wise); how will the text end up in openSUSE RN? And how is openSUSE-specific part relevant for SLES customers if it appears in their RN? Wouldn't it make more sense to have two separate RN texts? #6: Stefan Hundhammer (shundhammer) (2016-05-18 17:22:21) Doc team please note that the release notes snippet is available in prettier format here: https://w3.suse.de/~shundhammer/release-notes-var-cache-subvol.txt + #10: Jiri Srain (jsrain) (2016-05-30 13:35:41) + The feature is basically done, closing this feature, RNs can still be + adjusted if necessary. + According to Ludwig, the RNs for openSUSE are not built of Fate, but + need to be adjusted in it, therefore I would suggest to remove openSUSE + from this text and create an openSUSE-specific version. Release Notes: Move /var/cache into an own subvolume for snapshots and rollback Challenge: /var/cache contains a lot of very volatile data, like the zypper cache with RPM packages in a lot of different versions for each update. Due to this volatility, the size a snapshot needs increases very fast for data that are mostly redundant. Solution: To solve this, /var/cache should be moved into a separate subvolume. If you install with SLES12 SP2 or newer, this is done automatically during installation. For existing root file systems, do these steps manually: - Find out the device name (/dev/sda2, /dev/sda3 etc.) of the root file system: df / - Identify the parent subvolume of all the other subvolumes. For SLE 12 and recent Tumbleweed installations, this is a subvolume named "@". For openSUSE 13.2 and older Tumbleweed installations, this it the unnamed toplevel subvolume with ID 5. Check if you have a '@' subvolume: btrfs subvolume list / | grep '@' If the output of this command is empty, you don't have a subvolume named '@'. In that case, use the subvolume with ID 5. - If you have a '@' subvolume, mount that subvolume to a temporary mount point (using /mnt in this description): mount <root_device> -o subvol=@ /mnt - If you don't have a '@' subvolume (and only then!), mount subvolume ID 5 instead: mount <root_device> -o subvolid=5 /mnt - In either case, create a new subvolume: btrfs subvol create /mnt/var/cache - Move all files and directories from the root file system's /var/cache to the new subvolume: mv /var/cache/* /mnt/var/cache/ - Unmount the subvolume from the temporary mount point: umount /mnt - Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. Make sure to leave the UUID untouched (this is the root file systems's UUID) and change the subvolume name and its mount point consistently to /var/cache. - Mount the new subvolume as specified in /etc/fstab: mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Jiri Srain (jsrain) Feature #320834, revision 25 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice #5: Stefan Hundhammer (shundhammer) (2016-05-18 17:18:48) (reply to #4) Thanks for the hint, added that case to the release notes section. #7: Jiri Srain (jsrain) (2016-05-19 08:13:32) (reply to #5) The RN entry (as well as this Fate) is for SLES - we should IMO leave openSUSE out of the release notes completely and possibly create a separate RN entry (separate Fate?) for openSUSE. Alternatively, would it make sense to leave out the specific version completely? After all, I would not be surprised if upgrades from latest SLE11 SPs (direct or indirect) would behave the same as 13.2... #8: Thorsten Kukuk (kukuk) (2016-05-19 09:06:25) (reply to #7) Differentiating this between openSUSE and SLES is a good idea, since no openSUSE user will read the SLES release notes. Removing the version numbers is bad, since this are the important information. And snapshot/rollback does not work if you are coming from SLES11, since SLES11 has /boot on an extra partition. So SLES12 only is correct. #9: Jiri Srain (jsrain) (2016-05-19 10:11:11) (reply to #8) Not sure I got yoru comment right, my main point was: This feature is for SLES only (Fate-wise); how will the text end up in openSUSE RN? And how is openSUSE-specific part relevant for SLES customers if it appears in their RN? Wouldn't it make more sense to have two separate RN texts? #6: Stefan Hundhammer (shundhammer) (2016-05-18 17:22:21) Doc team please note that the release notes snippet is available in prettier format here: https://w3.suse.de/~shundhammer/release-notes-var-cache-subvol.txt #10: Jiri Srain (jsrain) (2016-05-30 13:35:41) The feature is basically done, closing this feature, RNs can still be adjusted if necessary. According to Ludwig, the RNs for openSUSE are not built of Fate, but need to be adjusted in it, therefore I would suggest to remove openSUSE from this text and create an openSUSE-specific version. + #11: Jiri Srain (jsrain) (2016-05-30 13:43:30) (reply to #10) + Reading Ludwig's email again, I'm a bit puzzled about how openSUSE RNs + are generated :-/ Release Notes: Move /var/cache into an own subvolume for snapshots and rollback Challenge: /var/cache contains a lot of very volatile data, like the zypper cache with RPM packages in a lot of different versions for each update. Due to this volatility, the size a snapshot needs increases very fast for data that are mostly redundant. Solution: To solve this, /var/cache should be moved into a separate subvolume. If you install with SLES12 SP2 or newer, this is done automatically during installation. For existing root file systems, do these steps manually: - Find out the device name (/dev/sda2, /dev/sda3 etc.) of the root file system: df / - Identify the parent subvolume of all the other subvolumes. For SLE 12 and recent Tumbleweed installations, this is a subvolume named "@". For openSUSE 13.2 and older Tumbleweed installations, this it the unnamed toplevel subvolume with ID 5. Check if you have a '@' subvolume: btrfs subvolume list / | grep '@' If the output of this command is empty, you don't have a subvolume named '@'. In that case, use the subvolume with ID 5. - If you have a '@' subvolume, mount that subvolume to a temporary mount point (using /mnt in this description): mount <root_device> -o subvol=@ /mnt - If you don't have a '@' subvolume (and only then!), mount subvolume ID 5 instead: mount <root_device> -o subvolid=5 /mnt - In either case, create a new subvolume: btrfs subvol create /mnt/var/cache - Move all files and directories from the root file system's /var/cache to the new subvolume: mv /var/cache/* /mnt/var/cache/ - Unmount the subvolume from the temporary mount point: umount /mnt - Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. Make sure to leave the UUID untouched (this is the root file systems's UUID) and change the subvolume name and its mount point consistently to /var/cache. - Mount the new subvolume as specified in /etc/fstab: mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Stefan Knorr (stfnknorr) Feature #320834, revision 26 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice #5: Stefan Hundhammer (shundhammer) (2016-05-18 17:18:48) (reply to #4) Thanks for the hint, added that case to the release notes section. #7: Jiri Srain (jsrain) (2016-05-19 08:13:32) (reply to #5) The RN entry (as well as this Fate) is for SLES - we should IMO leave openSUSE out of the release notes completely and possibly create a separate RN entry (separate Fate?) for openSUSE. Alternatively, would it make sense to leave out the specific version completely? After all, I would not be surprised if upgrades from latest SLE11 SPs (direct or indirect) would behave the same as 13.2... #8: Thorsten Kukuk (kukuk) (2016-05-19 09:06:25) (reply to #7) Differentiating this between openSUSE and SLES is a good idea, since no openSUSE user will read the SLES release notes. Removing the version numbers is bad, since this are the important information. And snapshot/rollback does not work if you are coming from SLES11, since SLES11 has /boot on an extra partition. So SLES12 only is correct. #9: Jiri Srain (jsrain) (2016-05-19 10:11:11) (reply to #8) Not sure I got yoru comment right, my main point was: This feature is for SLES only (Fate-wise); how will the text end up in openSUSE RN? And how is openSUSE-specific part relevant for SLES customers if it appears in their RN? Wouldn't it make more sense to have two separate RN texts? #6: Stefan Hundhammer (shundhammer) (2016-05-18 17:22:21) Doc team please note that the release notes snippet is available in prettier format here: https://w3.suse.de/~shundhammer/release-notes-var-cache-subvol.txt #10: Jiri Srain (jsrain) (2016-05-30 13:35:41) The feature is basically done, closing this feature, RNs can still be adjusted if necessary. According to Ludwig, the RNs for openSUSE are not built of Fate, but need to be adjusted in it, therefore I would suggest to remove openSUSE from this text and create an openSUSE-specific version. #11: Jiri Srain (jsrain) (2016-05-30 13:43:30) (reply to #10) Reading Ludwig's email again, I'm a bit puzzled about how openSUSE RNs are generated :-/ - Release Notes: Move /var/cache into an own subvolume for snapshots and - rollback + Release Notes: /var/cache on an Own Subvolume for Snapshots and + Rollback Challenge: - /var/cache contains a lot of very volatile data, like the zypper cache - with RPM packages in a lot of different versions for each update. Due - to this volatility, the size a snapshot needs increases very fast for - data that are mostly redundant. + /var/cache contains a lot of very volatile data, like the Zypper cache + with RPM packages in a lot of different versions for each update. As a + result of storing data that is mostly redundant but highly volatile, + the amount of disk space a snapshot occupies can increase very fast. Solution: To solve this, /var/cache should be moved into a separate subvolume. If - you install with SLES12 SP2 or newer, this is done automatically during + you install with SLE 12 SP2 or newer, this is done automatically during installation. For existing root file systems, do these steps manually: - - Find out the device name (/dev/sda2, /dev/sda3 etc.) of the root file - system: df / - - Identify the parent subvolume of all the other subvolumes. For SLE 12 - and recent Tumbleweed installations, this is a subvolume named "@". For - openSUSE 13.2 and older Tumbleweed installations, this it the unnamed - toplevel subvolume with ID 5. Check if you have a '@' subvolume: - btrfs subvolume list / | grep '@' - If the output of this command is empty, you don't have a subvolume - named '@'. In that case, use the subvolume with ID 5. - - If you have a '@' subvolume, mount that subvolume to a temporary - mount point (using /mnt in this description): - mount <root_device> -o subvol=@ /mnt - - If you don't have a '@' subvolume (and only then!), mount subvolume - ID 5 instead: - mount <root_device> -o subvolid=5 /mnt - - In either case, create a new subvolume: - btrfs subvol create /mnt/var/cache - - Move all files and directories from the root file system's /var/cache - to the new subvolume: - mv /var/cache/* /mnt/var/cache/ - - Unmount the subvolume from the temporary mount point: - umount /mnt - - Add an entry to /etc/fstab for the new /var/cache subvolume. Use an + 1) Find out the device name ( /dev/sda2 , /dev/sda3 etc.) of the root + file system: df / + 2) Identify the parent subvolume of all the other subvolumes. For SLE + 12 installations, this is a subvolume named @ . To check if you have a + @ subvolume, use: btrfs subvolume list / | grep '@' . If the output of + this command is empty, you do not have a subvolume named @ . In that + case, you may be able to proceed the subvolume with ID 5 which was used + in older versions of SLE. + 3) Now mount the requisite subvolume + * If you have a @ subvolume, mount that subvolume to a temporary mount + point: mount <root_device> -o subvol=@ /mnt + * If you don't have a @ subvolume, mount subvolume ID 5 instead: mount + <root_device> -o subvolid=5 /mnt + 4) In either case, create a new subvolume: btrfs subvol create + /mnt/var/cache + 5) Move all files and directories from the root file system's /var/cache + to the new subvolume: mv /var/cache/* /mnt/var/cache/ + 6) Unmount the subvolume from the temporary mount point: umount /mnt + 7) Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. Make sure to leave the UUID untouched (this is the root file systems's UUID) and change the subvolume name and its mount point consistently to /var/cache. - - Mount the new subvolume as specified in /etc/fstab: - mount /var/cache + 8) Mount the new subvolume as specified in /etc/fstab: mount + /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Stefan Knorr (stfnknorr) Feature #320834, revision 27 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice #5: Stefan Hundhammer (shundhammer) (2016-05-18 17:18:48) (reply to #4) Thanks for the hint, added that case to the release notes section. #7: Jiri Srain (jsrain) (2016-05-19 08:13:32) (reply to #5) The RN entry (as well as this Fate) is for SLES - we should IMO leave openSUSE out of the release notes completely and possibly create a separate RN entry (separate Fate?) for openSUSE. Alternatively, would it make sense to leave out the specific version completely? After all, I would not be surprised if upgrades from latest SLE11 SPs (direct or indirect) would behave the same as 13.2... #8: Thorsten Kukuk (kukuk) (2016-05-19 09:06:25) (reply to #7) Differentiating this between openSUSE and SLES is a good idea, since no openSUSE user will read the SLES release notes. Removing the version numbers is bad, since this are the important information. And snapshot/rollback does not work if you are coming from SLES11, since SLES11 has /boot on an extra partition. So SLES12 only is correct. #9: Jiri Srain (jsrain) (2016-05-19 10:11:11) (reply to #8) Not sure I got yoru comment right, my main point was: This feature is for SLES only (Fate-wise); how will the text end up in openSUSE RN? And how is openSUSE-specific part relevant for SLES customers if it appears in their RN? Wouldn't it make more sense to have two separate RN texts? #6: Stefan Hundhammer (shundhammer) (2016-05-18 17:22:21) Doc team please note that the release notes snippet is available in prettier format here: https://w3.suse.de/~shundhammer/release-notes-var-cache-subvol.txt #10: Jiri Srain (jsrain) (2016-05-30 13:35:41) The feature is basically done, closing this feature, RNs can still be adjusted if necessary. According to Ludwig, the RNs for openSUSE are not built of Fate, but need to be adjusted in it, therefore I would suggest to remove openSUSE from this text and create an openSUSE-specific version. #11: Jiri Srain (jsrain) (2016-05-30 13:43:30) (reply to #10) Reading Ludwig's email again, I'm a bit puzzled about how openSUSE RNs are generated :-/ Release Notes: /var/cache on an Own Subvolume for Snapshots and Rollback Challenge: /var/cache contains a lot of very volatile data, like the Zypper cache with RPM packages in a lot of different versions for each update. As a result of storing data that is mostly redundant but highly volatile, the amount of disk space a snapshot occupies can increase very fast. Solution: To solve this, /var/cache should be moved into a separate subvolume. If you install with SLE 12 SP2 or newer, this is done automatically during installation. For existing root file systems, do these steps manually: 1) Find out the device name ( /dev/sda2 , /dev/sda3 etc.) of the root file system: df / 2) Identify the parent subvolume of all the other subvolumes. For SLE 12 installations, this is a subvolume named @ . To check if you have a @ subvolume, use: btrfs subvolume list / | grep '@' . If the output of this command is empty, you do not have a subvolume named @ . In that case, you may be able to proceed the subvolume with ID 5 which was used in older versions of SLE. 3) Now mount the requisite subvolume * If you have a @ subvolume, mount that subvolume to a temporary mount point: mount <root_device> -o subvol=@ /mnt * If you don't have a @ subvolume, mount subvolume ID 5 instead: mount <root_device> -o subvolid=5 /mnt 4) In either case, create a new subvolume: btrfs subvol create /mnt/var/cache 5) Move all files and directories from the root file system's /var/cache to the new subvolume: mv /var/cache/* /mnt/var/cache/ 6) Unmount the subvolume from the temporary mount point: umount /mnt 7) Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. Make sure to leave the - UUID untouched (this is the root file systems's UUID) and change the + UUID untouched (this is the root file system's UUID) and change the subvolume name and its mount point consistently to /var/cache . 8) Mount the new subvolume as specified in /etc/fstab: mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Dominique Leuenberger (dimstar_suse) Feature #320834, revision 29 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice #5: Stefan Hundhammer (shundhammer) (2016-05-18 17:18:48) (reply to #4) Thanks for the hint, added that case to the release notes section. #7: Jiri Srain (jsrain) (2016-05-19 08:13:32) (reply to #5) The RN entry (as well as this Fate) is for SLES - we should IMO leave openSUSE out of the release notes completely and possibly create a separate RN entry (separate Fate?) for openSUSE. Alternatively, would it make sense to leave out the specific version completely? After all, I would not be surprised if upgrades from latest SLE11 SPs (direct or indirect) would behave the same as 13.2... #8: Thorsten Kukuk (kukuk) (2016-05-19 09:06:25) (reply to #7) Differentiating this between openSUSE and SLES is a good idea, since no openSUSE user will read the SLES release notes. Removing the version numbers is bad, since this are the important information. And snapshot/rollback does not work if you are coming from SLES11, since SLES11 has /boot on an extra partition. So SLES12 only is correct. #9: Jiri Srain (jsrain) (2016-05-19 10:11:11) (reply to #8) Not sure I got yoru comment right, my main point was: This feature is for SLES only (Fate-wise); how will the text end up in openSUSE RN? And how is openSUSE-specific part relevant for SLES customers if it appears in their RN? Wouldn't it make more sense to have two separate RN texts? #6: Stefan Hundhammer (shundhammer) (2016-05-18 17:22:21) Doc team please note that the release notes snippet is available in prettier format here: https://w3.suse.de/~shundhammer/release-notes-var-cache-subvol.txt + #12: Dominique Leuenberger (dimstar_suse) (2016-07-21 10:55:42) (reply + to #6) + I just tried to 'play' the way of fixing it through - without success + though (note, I did this on a TW install, but that should be close + enough in any case) >Find out the device name (/dev/sda2, /dev/sda3 + etc.) of the root file system: ==> /dev/sda3 (no problem so far) > + btrfs subvolume list / | grep '@' ==> no output (btrfs subvolume list / + shows "top level 5" all over the place, indicating that 'subvolid 5' is + likely what I need) > mount /dev/sda3 -o subvolid=5 /mnt => + successfully mounts; BUT as expected by me, there is of course + /mnt/var/cache populated already; after all, I DO have this in my root + filesystem.. this then leads to: > btrfs subvol create /mnt/var/cache + ERROR: target path already exists: /mnt/var/cache + There must be some steps wrongly documented or omitted. #10: Jiri Srain (jsrain) (2016-05-30 13:35:41) The feature is basically done, closing this feature, RNs can still be adjusted if necessary. According to Ludwig, the RNs for openSUSE are not built of Fate, but need to be adjusted in it, therefore I would suggest to remove openSUSE from this text and create an openSUSE-specific version. #11: Jiri Srain (jsrain) (2016-05-30 13:43:30) (reply to #10) Reading Ludwig's email again, I'm a bit puzzled about how openSUSE RNs are generated :-/ Release Notes: /var/cache on an Own Subvolume for Snapshots and Rollback Challenge: /var/cache contains a lot of very volatile data, like the Zypper cache with RPM packages in a lot of different versions for each update. As a result of storing data that is mostly redundant but highly volatile, the amount of disk space a snapshot occupies can increase very fast. Solution: To solve this, /var/cache should be moved into a separate subvolume. If you install with SLE 12 SP2 or newer, this is done automatically during installation. For existing root file systems, do these steps manually: 1) Find out the device name ( /dev/sda2 , /dev/sda3 etc.) of the root file system: df / 2) Identify the parent subvolume of all the other subvolumes. For SLE 12 installations, this is a subvolume named @ . To check if you have a @ subvolume, use: btrfs subvolume list / | grep '@' . If the output of this command is empty, you do not have a subvolume named @ . In that case, you may be able to proceed the subvolume with ID 5 which was used in older versions of SLE. 3) Now mount the requisite subvolume * If you have a @ subvolume, mount that subvolume to a temporary mount point: mount <root_device> -o subvol=@ /mnt * If you don't have a @ subvolume, mount subvolume ID 5 instead: mount <root_device> -o subvolid=5 /mnt 4) In either case, create a new subvolume: btrfs subvol create /mnt/var/cache 5) Move all files and directories from the root file system's /var/cache to the new subvolume: mv /var/cache/* /mnt/var/cache/ 6) Unmount the subvolume from the temporary mount point: umount /mnt 7) Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. Make sure to leave the UUID untouched (this is the root file system's UUID) and change the subvolume name and its mount point consistently to /var/cache . 8) Mount the new subvolume as specified in /etc/fstab: mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Stefan Knorr (stfnknorr) Feature #320834, revision 30 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice #5: Stefan Hundhammer (shundhammer) (2016-05-18 17:18:48) (reply to #4) Thanks for the hint, added that case to the release notes section. #7: Jiri Srain (jsrain) (2016-05-19 08:13:32) (reply to #5) The RN entry (as well as this Fate) is for SLES - we should IMO leave openSUSE out of the release notes completely and possibly create a separate RN entry (separate Fate?) for openSUSE. Alternatively, would it make sense to leave out the specific version completely? After all, I would not be surprised if upgrades from latest SLE11 SPs (direct or indirect) would behave the same as 13.2... #8: Thorsten Kukuk (kukuk) (2016-05-19 09:06:25) (reply to #7) Differentiating this between openSUSE and SLES is a good idea, since no openSUSE user will read the SLES release notes. Removing the version numbers is bad, since this are the important information. And snapshot/rollback does not work if you are coming from SLES11, since SLES11 has /boot on an extra partition. So SLES12 only is correct. #9: Jiri Srain (jsrain) (2016-05-19 10:11:11) (reply to #8) Not sure I got yoru comment right, my main point was: This feature is for SLES only (Fate-wise); how will the text end up in openSUSE RN? And how is openSUSE-specific part relevant for SLES customers if it appears in their RN? Wouldn't it make more sense to have two separate RN texts? #6: Stefan Hundhammer (shundhammer) (2016-05-18 17:22:21) Doc team please note that the release notes snippet is available in prettier format here: https://w3.suse.de/~shundhammer/release-notes-var-cache-subvol.txt #12: Dominique Leuenberger (dimstar_suse) (2016-07-21 10:55:42) (reply to #6) I just tried to 'play' the way of fixing it through - without success though (note, I did this on a TW install, but that should be close enough in any case) >Find out the device name (/dev/sda2, /dev/sda3 etc.) of the root file system: ==> /dev/sda3 (no problem so far) > btrfs subvolume list / | grep '@' ==> no output (btrfs subvolume list / shows "top level 5" all over the place, indicating that 'subvolid 5' is likely what I need) > mount /dev/sda3 -o subvolid=5 /mnt => successfully mounts; BUT as expected by me, there is of course /mnt/var/cache populated already; after all, I DO have this in my root filesystem.. this then leads to: > btrfs subvol create /mnt/var/cache ERROR: target path already exists: /mnt/var/cache There must be some steps wrongly documented or omitted. #10: Jiri Srain (jsrain) (2016-05-30 13:35:41) The feature is basically done, closing this feature, RNs can still be adjusted if necessary. According to Ludwig, the RNs for openSUSE are not built of Fate, but need to be adjusted in it, therefore I would suggest to remove openSUSE from this text and create an openSUSE-specific version. #11: Jiri Srain (jsrain) (2016-05-30 13:43:30) (reply to #10) Reading Ludwig's email again, I'm a bit puzzled about how openSUSE RNs are generated :-/ Release Notes: /var/cache on an Own Subvolume for Snapshots and Rollback Challenge: /var/cache contains a lot of very volatile data, like the Zypper cache with RPM packages in a lot of different versions for each update. As a result of storing data that is mostly redundant but highly volatile, the amount of disk space a snapshot occupies can increase very fast. Solution: To solve this, /var/cache should be moved into a separate subvolume. If you install with SLE 12 SP2 or newer, this is done automatically during installation. For existing root file systems, do these steps manually: 1) Find out the device name ( /dev/sda2 , /dev/sda3 etc.) of the root file system: df / 2) Identify the parent subvolume of all the other subvolumes. For SLE 12 installations, this is a subvolume named @ . To check if you have a @ subvolume, use: btrfs subvolume list / | grep '@' . If the output of this command is empty, you do not have a subvolume named @ . In that case, you may be able to proceed the subvolume with ID 5 which was used in older versions of SLE. 3) Now mount the requisite subvolume * If you have a @ subvolume, mount that subvolume to a temporary mount point: mount <root_device> -o subvol=@ /mnt * If you don't have a @ subvolume, mount subvolume ID 5 instead: mount <root_device> -o subvolid=5 /mnt - 4) In either case, create a new subvolume: btrfs subvol create + 4) /mnt/var/cache can already exist and could be the same directory as + /var/cache . To avoid data loss, move it: mv /mnt/var/cache + /mnt/var/cache.old + 5) In either case, create a new subvolume: btrfs subvol create /mnt/var/cache - 5) Move all files and directories from the root file system's /var/cache - to the new subvolume: mv /var/cache/* /mnt/var/cache/ - 6) Unmount the subvolume from the temporary mount point: umount /mnt - 7) Add an entry to /etc/fstab for the new /var/cache subvolume. Use an + 6) If there is now a directory /var/cache.old , move it to the new + location: mv /var/cache.old/* /mnt/var/cache . If that is not the case, + instead do: mv /var/cache/* /mnt/var/cache/ + 7) Optionally, remove /mnt/var/cache.old : rm -rf /mnt/var/cache.old + 8) Unmount the subvolume from the temporary mount point: umount /mnt + 9) Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. Make sure to leave the UUID untouched (this is the root file system's UUID) and change the subvolume name and its mount point consistently to /var/cache . - 8) Mount the new subvolume as specified in /etc/fstab: mount + 10) Mount the new subvolume as specified in /etc/fstab: mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Stefan Knorr (stfnknorr) Feature #320834, revision 31 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice #5: Stefan Hundhammer (shundhammer) (2016-05-18 17:18:48) (reply to #4) Thanks for the hint, added that case to the release notes section. #7: Jiri Srain (jsrain) (2016-05-19 08:13:32) (reply to #5) The RN entry (as well as this Fate) is for SLES - we should IMO leave openSUSE out of the release notes completely and possibly create a separate RN entry (separate Fate?) for openSUSE. Alternatively, would it make sense to leave out the specific version completely? After all, I would not be surprised if upgrades from latest SLE11 SPs (direct or indirect) would behave the same as 13.2... #8: Thorsten Kukuk (kukuk) (2016-05-19 09:06:25) (reply to #7) Differentiating this between openSUSE and SLES is a good idea, since no openSUSE user will read the SLES release notes. Removing the version numbers is bad, since this are the important information. And snapshot/rollback does not work if you are coming from SLES11, since SLES11 has /boot on an extra partition. So SLES12 only is correct. #9: Jiri Srain (jsrain) (2016-05-19 10:11:11) (reply to #8) Not sure I got yoru comment right, my main point was: This feature is for SLES only (Fate-wise); how will the text end up in openSUSE RN? And how is openSUSE-specific part relevant for SLES customers if it appears in their RN? Wouldn't it make more sense to have two separate RN texts? #6: Stefan Hundhammer (shundhammer) (2016-05-18 17:22:21) Doc team please note that the release notes snippet is available in prettier format here: https://w3.suse.de/~shundhammer/release-notes-var-cache-subvol.txt #12: Dominique Leuenberger (dimstar_suse) (2016-07-21 10:55:42) (reply to #6) I just tried to 'play' the way of fixing it through - without success though (note, I did this on a TW install, but that should be close enough in any case) >Find out the device name (/dev/sda2, /dev/sda3 etc.) of the root file system: ==> /dev/sda3 (no problem so far) > btrfs subvolume list / | grep '@' ==> no output (btrfs subvolume list / shows "top level 5" all over the place, indicating that 'subvolid 5' is likely what I need) > mount /dev/sda3 -o subvolid=5 /mnt => successfully mounts; BUT as expected by me, there is of course /mnt/var/cache populated already; after all, I DO have this in my root filesystem.. this then leads to: > btrfs subvol create /mnt/var/cache ERROR: target path already exists: /mnt/var/cache There must be some steps wrongly documented or omitted. #10: Jiri Srain (jsrain) (2016-05-30 13:35:41) The feature is basically done, closing this feature, RNs can still be adjusted if necessary. According to Ludwig, the RNs for openSUSE are not built of Fate, but need to be adjusted in it, therefore I would suggest to remove openSUSE from this text and create an openSUSE-specific version. #11: Jiri Srain (jsrain) (2016-05-30 13:43:30) (reply to #10) Reading Ludwig's email again, I'm a bit puzzled about how openSUSE RNs are generated :-/ Release Notes: /var/cache on an Own Subvolume for Snapshots and Rollback Challenge: - /var/cache contains a lot of very volatile data, like the Zypper cache - with RPM packages in a lot of different versions for each update. As a - result of storing data that is mostly redundant but highly volatile, - the amount of disk space a snapshot occupies can increase very fast. + /var/cache contains very volatile data, like the Zypper cache with RPM + packages in different versions for each update. As a result of storing + data that is mostly redundant but highly volatile, the amount of disk + space a snapshot occupies can increase very fast. Solution: - To solve this, /var/cache should be moved into a separate subvolume. If - you install with SLE 12 SP2 or newer, this is done automatically during - installation. For existing root file systems, do these steps manually: + To solve this, move /var/cache to a separate subvolume. On fresh + installations of SLE 12 SP2 or newer, this is done automatically. To + convert an existing root file system, perform the following steps: 1) Find out the device name ( /dev/sda2 , /dev/sda3 etc.) of the root file system: df / 2) Identify the parent subvolume of all the other subvolumes. For SLE 12 installations, this is a subvolume named @ . To check if you have a @ subvolume, use: btrfs subvolume list / | grep '@' . If the output of this command is empty, you do not have a subvolume named @ . In that - case, you may be able to proceed the subvolume with ID 5 which was used - in older versions of SLE. - 3) Now mount the requisite subvolume + case, you may be able to proceed with subvolume ID 5 which was used in + older versions of SLE. + 3) Now mount the requisite subvolume. * If you have a @ subvolume, mount that subvolume to a temporary mount point: mount <root_device> -o subvol=@ /mnt * If you don't have a @ subvolume, mount subvolume ID 5 instead: mount <root_device> -o subvolid=5 /mnt 4) /mnt/var/cache can already exist and could be the same directory as /var/cache . To avoid data loss, move it: mv /mnt/var/cache /mnt/var/cache.old 5) In either case, create a new subvolume: btrfs subvol create /mnt/var/cache 6) If there is now a directory /var/cache.old , move it to the new location: mv /var/cache.old/* /mnt/var/cache . If that is not the case, instead do: mv /var/cache/* /mnt/var/cache/ 7) Optionally, remove /mnt/var/cache.old : rm -rf /mnt/var/cache.old 8) Unmount the subvolume from the temporary mount point: umount /mnt 9) Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. Make sure to leave the UUID untouched (this is the root file system's UUID) and change the subvolume name and its mount point consistently to /var/cache . 10) Mount the new subvolume as specified in /etc/fstab: mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Stefan Brüns (StefanBruens) Feature #320834, revision 32 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice #5: Stefan Hundhammer (shundhammer) (2016-05-18 17:18:48) (reply to #4) Thanks for the hint, added that case to the release notes section. #7: Jiri Srain (jsrain) (2016-05-19 08:13:32) (reply to #5) The RN entry (as well as this Fate) is for SLES - we should IMO leave openSUSE out of the release notes completely and possibly create a separate RN entry (separate Fate?) for openSUSE. Alternatively, would it make sense to leave out the specific version completely? After all, I would not be surprised if upgrades from latest SLE11 SPs (direct or indirect) would behave the same as 13.2... #8: Thorsten Kukuk (kukuk) (2016-05-19 09:06:25) (reply to #7) Differentiating this between openSUSE and SLES is a good idea, since no openSUSE user will read the SLES release notes. Removing the version numbers is bad, since this are the important information. And snapshot/rollback does not work if you are coming from SLES11, since SLES11 has /boot on an extra partition. So SLES12 only is correct. #9: Jiri Srain (jsrain) (2016-05-19 10:11:11) (reply to #8) Not sure I got yoru comment right, my main point was: This feature is for SLES only (Fate-wise); how will the text end up in openSUSE RN? And how is openSUSE-specific part relevant for SLES customers if it appears in their RN? Wouldn't it make more sense to have two separate RN texts? #6: Stefan Hundhammer (shundhammer) (2016-05-18 17:22:21) Doc team please note that the release notes snippet is available in prettier format here: https://w3.suse.de/~shundhammer/release-notes-var-cache-subvol.txt #12: Dominique Leuenberger (dimstar_suse) (2016-07-21 10:55:42) (reply to #6) I just tried to 'play' the way of fixing it through - without success though (note, I did this on a TW install, but that should be close enough in any case) >Find out the device name (/dev/sda2, /dev/sda3 etc.) of the root file system: ==> /dev/sda3 (no problem so far) > btrfs subvolume list / | grep '@' ==> no output (btrfs subvolume list / shows "top level 5" all over the place, indicating that 'subvolid 5' is likely what I need) > mount /dev/sda3 -o subvolid=5 /mnt => successfully mounts; BUT as expected by me, there is of course /mnt/var/cache populated already; after all, I DO have this in my root filesystem.. this then leads to: > btrfs subvol create /mnt/var/cache ERROR: target path already exists: /mnt/var/cache There must be some steps wrongly documented or omitted. + #13: Stefan Brüns (stefanbruens) (2016-08-12 12:50:45) (reply to #12) + Is the relevant RN part available somewhere accessible? I did the + switch on my Laptop based on some stuff I found on the net, but my + desktop is still waiting for the switch, so I would like to try the RN + documentation. #10: Jiri Srain (jsrain) (2016-05-30 13:35:41) The feature is basically done, closing this feature, RNs can still be adjusted if necessary. According to Ludwig, the RNs for openSUSE are not built of Fate, but need to be adjusted in it, therefore I would suggest to remove openSUSE from this text and create an openSUSE-specific version. #11: Jiri Srain (jsrain) (2016-05-30 13:43:30) (reply to #10) Reading Ludwig's email again, I'm a bit puzzled about how openSUSE RNs are generated :-/ Release Notes: /var/cache on an Own Subvolume for Snapshots and Rollback Challenge: /var/cache contains very volatile data, like the Zypper cache with RPM packages in different versions for each update. As a result of storing data that is mostly redundant but highly volatile, the amount of disk space a snapshot occupies can increase very fast. Solution: To solve this, move /var/cache to a separate subvolume. On fresh installations of SLE 12 SP2 or newer, this is done automatically. To convert an existing root file system, perform the following steps: 1) Find out the device name ( /dev/sda2 , /dev/sda3 etc.) of the root file system: df / 2) Identify the parent subvolume of all the other subvolumes. For SLE 12 installations, this is a subvolume named @ . To check if you have a @ subvolume, use: btrfs subvolume list / | grep '@' . If the output of this command is empty, you do not have a subvolume named @ . In that case, you may be able to proceed with subvolume ID 5 which was used in older versions of SLE. 3) Now mount the requisite subvolume. * If you have a @ subvolume, mount that subvolume to a temporary mount point: mount <root_device> -o subvol=@ /mnt * If you don't have a @ subvolume, mount subvolume ID 5 instead: mount <root_device> -o subvolid=5 /mnt 4) /mnt/var/cache can already exist and could be the same directory as /var/cache . To avoid data loss, move it: mv /mnt/var/cache /mnt/var/cache.old 5) In either case, create a new subvolume: btrfs subvol create /mnt/var/cache 6) If there is now a directory /var/cache.old , move it to the new location: mv /var/cache.old/* /mnt/var/cache . If that is not the case, instead do: mv /var/cache/* /mnt/var/cache/ 7) Optionally, remove /mnt/var/cache.old : rm -rf /mnt/var/cache.old 8) Unmount the subvolume from the temporary mount point: umount /mnt 9) Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. Make sure to leave the UUID untouched (this is the root file system's UUID) and change the subvolume name and its mount point consistently to /var/cache . 10) Mount the new subvolume as specified in /etc/fstab: mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
Feature changed by: Stefan Knorr (stfnknorr) Feature #320834, revision 33 Title: [BETA 1 / 2] Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) - Developer: YaST Maintainers mailing-list (yast2-maintainers) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot as they will be only deleted after creating the snapshot. This is a big problem if you regular update online, it will eat up your diskspace very fast. The same is true for all other cached data, there is no real sense in having them included into a snapshot, since they change very fast, they will only eat up disk space. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Documentation Impact: snapper.xml Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. Discussion: #1: Hannes Kühnemund (hkuehnemund) (2016-05-04 13:33:56) Just read the conversation on research and passed on to PrjMgr. #2: Jiri Srain (jsrain) (2016-05-05 13:28:59) Updated yast2-storage is on its way to SP2:GA (https://build.suse.de/request/show/114103). Keeping open for now, since the release notes entry to document how to create such subvolume in an installed system (without having any side effects) is missing. #3: Thorsten Kukuk (kukuk) (2016-05-10 13:42:43) I added some first, rough text for the release-notes. #4: Stefan Brüns (stefanbruens) (2016-05-18 03:07:18) on openSUSE, / is not created as subvolume @ (at least it was not with 13.2). Documentation how to mv /var/cache in this case would be nice #5: Stefan Hundhammer (shundhammer) (2016-05-18 17:18:48) (reply to #4) Thanks for the hint, added that case to the release notes section. #7: Jiri Srain (jsrain) (2016-05-19 08:13:32) (reply to #5) The RN entry (as well as this Fate) is for SLES - we should IMO leave openSUSE out of the release notes completely and possibly create a separate RN entry (separate Fate?) for openSUSE. Alternatively, would it make sense to leave out the specific version completely? After all, I would not be surprised if upgrades from latest SLE11 SPs (direct or indirect) would behave the same as 13.2... #8: Thorsten Kukuk (kukuk) (2016-05-19 09:06:25) (reply to #7) Differentiating this between openSUSE and SLES is a good idea, since no openSUSE user will read the SLES release notes. Removing the version numbers is bad, since this are the important information. And snapshot/rollback does not work if you are coming from SLES11, since SLES11 has /boot on an extra partition. So SLES12 only is correct. #9: Jiri Srain (jsrain) (2016-05-19 10:11:11) (reply to #8) Not sure I got yoru comment right, my main point was: This feature is for SLES only (Fate-wise); how will the text end up in openSUSE RN? And how is openSUSE-specific part relevant for SLES customers if it appears in their RN? Wouldn't it make more sense to have two separate RN texts? #6: Stefan Hundhammer (shundhammer) (2016-05-18 17:22:21) Doc team please note that the release notes snippet is available in prettier format here: https://w3.suse.de/~shundhammer/release-notes-var-cache-subvol.txt #12: Dominique Leuenberger (dimstar_suse) (2016-07-21 10:55:42) (reply to #6) I just tried to 'play' the way of fixing it through - without success though (note, I did this on a TW install, but that should be close enough in any case) >Find out the device name (/dev/sda2, /dev/sda3 etc.) of the root file system: ==> /dev/sda3 (no problem so far) > btrfs subvolume list / | grep '@' ==> no output (btrfs subvolume list / shows "top level 5" all over the place, indicating that 'subvolid 5' is likely what I need) > mount /dev/sda3 -o subvolid=5 /mnt => successfully mounts; BUT as expected by me, there is of course /mnt/var/cache populated already; after all, I DO have this in my root filesystem.. this then leads to: > btrfs subvol create /mnt/var/cache ERROR: target path already exists: /mnt/var/cache There must be some steps wrongly documented or omitted. #13: Stefan Brüns (stefanbruens) (2016-08-12 12:50:45) (reply to #12) Is the relevant RN part available somewhere accessible? I did the switch on my Laptop based on some stuff I found on the net, but my desktop is still waiting for the switch, so I would like to try the RN documentation. #10: Jiri Srain (jsrain) (2016-05-30 13:35:41) The feature is basically done, closing this feature, RNs can still be adjusted if necessary. According to Ludwig, the RNs for openSUSE are not built of Fate, but need to be adjusted in it, therefore I would suggest to remove openSUSE from this text and create an openSUSE-specific version. #11: Jiri Srain (jsrain) (2016-05-30 13:43:30) (reply to #10) Reading Ludwig's email again, I'm a bit puzzled about how openSUSE RNs are generated :-/ Release Notes: /var/cache on an Own Subvolume for Snapshots and Rollback Challenge: /var/cache contains very volatile data, like the Zypper cache with RPM packages in different versions for each update. As a result of storing data that is mostly redundant but highly volatile, the amount of disk space a snapshot occupies can increase very fast. Solution: To solve this, move /var/cache to a separate subvolume. On fresh installations of SLE 12 SP2 or newer, this is done automatically. To convert an existing root file system, perform the following steps: 1) Find out the device name ( /dev/sda2 , /dev/sda3 etc.) of the root file system: df / 2) Identify the parent subvolume of all the other subvolumes. For SLE 12 installations, this is a subvolume named @ . To check if you have a @ subvolume, use: btrfs subvolume list / | grep '@' . If the output of this command is empty, you do not have a subvolume named @ . In that case, you may be able to proceed with subvolume ID 5 which was used in older versions of SLE. 3) Now mount the requisite subvolume. * If you have a @ subvolume, mount that subvolume to a temporary mount point: mount <root_device> -o subvol=@ /mnt * If you don't have a @ subvolume, mount subvolume ID 5 instead: mount <root_device> -o subvolid=5 /mnt 4) /mnt/var/cache can already exist and could be the same directory as /var/cache . To avoid data loss, move it: mv /mnt/var/cache /mnt/var/cache.old 5) In either case, create a new subvolume: btrfs subvol create /mnt/var/cache 6) If there is now a directory /var/cache.old , move it to the new location: mv /var/cache.old/* /mnt/var/cache . If that is not the case, instead do: mv /var/cache/* /mnt/var/cache/ 7) Optionally, remove /mnt/var/cache.old : rm -rf /mnt/var/cache.old 8) Unmount the subvolume from the temporary mount point: umount /mnt 9) Add an entry to /etc/fstab for the new /var/cache subvolume. Use an existing subvolume as a template to copy from. Make sure to leave the UUID untouched (this is the root file system's UUID) and change the subvolume name and its mount point consistently to /var/cache . 10) Mount the new subvolume as specified in /etc/fstab: mount /var/cache -- openSUSE Feature: https://features.opensuse.org/320834
participants (1)
-
fate_noreply@suse.de