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