Mailinglist Archive: opensuse-features (18 mails)

< Previous Next >
[openFATE 320834] [BETA 1 / 2] Create a /var/cache subvolume
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:

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:

Business case (Partner benefit): Save disk space by excluding irrelvant/outdated cached
data from snapshots.

#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
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
Documentation how to mv /var/cache in this case would be nice

#5: Stefan Hundhammer (shundhammer) (2016-05-18 17:18:48) (reply to
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

#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

#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:

#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

/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.

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
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

openSUSE Feature:

< Previous Next >
This Thread