On Tue, May 3, 2016 at 3:57 AM, Yamaban <foerster@lisas.de> wrote:
Here is why so much more for snapshotting:
A TW, fresh installed, no packages kept by zypper, takes for example 12-16 GB on disk (X11, XFCE / KDE / GNOME, Office pattern).
Kinda old now but openSUSE-Tumbleweed-GNOME-Live-x86_64-Snapshot20160307-Media.iso default partitioning and installation on a 1TiB device results in: Filesystem Size Used Avail Use% Mounted on /dev/vda2 41G 3.7G 35G 10% / Off hand this doesn't seem unreasonable. So I don't know where the problem is that some people are running into where they run out of space. I suspect it's some combination of snapper triggering on used% that's too high, and btrfsmaintenance-refresh.service being disabled by default. However, looking at /usr/share/btrfsmaintenance.sh it clearly needs updating. - snapshot aware defrag was pulled out of btrfs a while ago due to problems, so I question the value and appropriateness of btrfs-defrag.sh being run on a regular basis; - btrfs-trim.sh is obsoleted by fstrim.timer which is enabled by default, there's no good reason to run both of these; - btrfs-balance.sh uses filters -dusage=0 and -musage=0 which is now handled by the kernel, this should probably be something like -dusage=5 and -musage=15 to consolidate extents from minimally used chunks and then revert them to unallocated space. That this service isn't up to date is probably a good reason why it's not enabled by default right now, but then there's nothing to keep Btrfs from hitting enospc prematurely (until that work is done in the kernel which of course will happen eventually).
Now on Btrfs a snapshot happens, due to cow and hardlinks, no additional space is taken for non-changed files.
Next TW-upgrade comes: User calls zypper dup 1. zypper will snapshot (pre update), 2. zypper downloads all the packages (this takes extra space not needed later, if the packages are not kept), and installs them, 3. second snapshot (post update) happens.
The second snapshot is big, as it contains all the changed / added files.
AFAICT, the paired snapshots for a update will take up about the unpacked size of the updates each.
Snapshots don't take up space. They prevent files from being deleted, or more correctly, they cause file extents to be retained. So when updates happen that cause old binaries to be deleted in one subvolume, their extents aren't actually freed because the file exists in another subvolume still.
Repeat that circle a few weeks (up to 4 TW Releases per week) and without manual intervention, you have a overflowing root-fs, with all the errors and trouble.
Something else is going on. It's not the snapshot itself that's the problem, nor the default root fs size. Those are contributing factors in the problem revealing itself sooner than later, so if all that's done is increase root fs by 4x, you'll postpone the same exact problem for later, rather than actually solve the problem.
IMHO, either we get the tools in shape, and give propper defaults for rootfs size ( e.g. min 60GB with btrfs ) or will continue to get reports of 'no space left' for rootfs, or more users will become disatisfied with the state of TW and / or (open)SUSE in general.
When users report no space left / enospc, they need to be asked to report 'btrfs fi us' or at least 'btrfs fi df' if they're using older user space tools. Only that way can we have some idea which type of enospc is being hit and maybe what to do about it. But it's true that the default out of the box experience should not result in face planted file systems that have to be reinstalled. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org