On Tue, 3 May 2016 01:18, Matthias G. Eckermann <mge@...> wrote:
On 2016-05-02 T 16:06 -0500 Chan Ju Ping wrote:
On Monday, May 2, 2016 10:50:49 AM CDT Simon Lees wrote:
I tend to agree here, I hit this as well with basically a default installation on a month old laptop, if no one tells me they've raised a bug about this in the next 24 hrs i'll create one.
Cheers
If you file the bug, do put the link here, so I can add myself to it. Basically, it is easier to completely reinstall the system rather than fudge around with resizing the encrypted lvm partitions I now have in place. It would have been more convenient if any of the initial setup screens had mentioned how much space btrfs should have been given.
This question - how much space to reserve for snapshots - depends on multiple factors: - the size of your installation - the update behaviour of the distribution you are using (Tumbleweed and LEAP / SLE 12 have fundamentally different patterns) - the default settings for the number of snapshots - the cleanup policies, and in this context probably also the question, if the cleanup policies are executed at all (and not the system is sleeping or off)
In general, it is a good general advice, to 1. Execute the snapshot cleanup daily 2. Execute "btrfsmaintenance" daily (with a lightweight policy) 3. Reserve three times more space than the OS currently uses. This already has a safety buffer, and allows for a complete distribution update of the OS plus metadata.
Addenum to point 3: For TW the recommention of three times the space in use is a little short, but mostly useable for a non-snapshot fs. For a snapshot fs (here btrfs), do your self a big favor and do not go below 4 times the projected used space. 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). 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. 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. A full rebuild as it happend last week is then just the cherry on top of the disaster waiting to happen. If a user wants to 'keep packages' in zypper, the problem beocmes worse, fast. Either zypper snapshotting becomes a added functionality to clean up / remove old 'zypper update' snapshots, or zypper dup should give a heavy warning if there is less than 2.5 times the size of the update free, before the download is started. 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. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org