My system uses a 40 GB btrfs root partition.
I just updated to 20190612 and it did not went totally smooth.
zypper dup reported 3200 packages were to be updated.
I checked the available space with (I have it bound to an alias):
/usr/sbin/btrfs fi usage / 2>/dev/null | grep "Free (estimated)"
it reported 7.5GB free.
Thus I thought it should be sufficient for that massive update. I was wrong:
Zypper downloaded all packages fine then proceeded to install them and
midway there were a bunch
of out of disk space errors. Then it halted with a prompt to
retry/abort/etc.
I deleted the oldest snapshot taking a lot of space (several GB) with
'snapper delete', then resumed and it finished without error.
My question is how this situation could be avoided in the first place ?
Having a system with no disk space left is always dangerous as
the system can behave unpredictably: this also happened to me a few days
ago after installing a bunch of individual packages, then
suddenly journalctld and syslogd went berserk attempting to repeatedly
write to disk. I could recover the situation deleting a snapshot but the
situation
was a bit stressful because it seemed the system could become
unresponsive and unusuable at any time (bash complained, etc).
So I think it would be able to have 2 things:
- having zypper check it has enough space to perform the full update and
at least emit a warning. This is mostly important for 'zypper dup'.
Checking required space might be tricky
- having some facility at the system level that warn user of running out
of disk space
Also, I think a 40GB partition is not big enough to handle these super
large updates. If you have to delete snapshots manually preventively,
there's a size problem.
I understand these massive updates are rare, but still.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org