On 2/7/19 8:32 AM, Roger Oberholtzer wrote:
The problem is not df vs some better utility to determine available space. It is that the test by zypper does not account for all the space that may be needed to complete the update.
It is about BTRFS being "different" from (most/all?) other file system types: a) It is by nature that BTRFS needs almost double space for such huge updates because it keeps the old data in a snapshot. b) It does not expose the correct disk usage statistics via the kernel interfaces like all other file systems do since ages: statfs(2). Thus, df(1) doesn't have a chance, and simply reports those not-much-useful numbers it gets from BTRFS. And no, there is no upstream activity to add such special support to GNU coreutils' df(1). On my home PC, I'm using a traditional EXT4, so I can easily live with 20G for "/" ... still I need the same size for regular backup space. The difference for me is that I can trust the numbers df(1) is getting from the kernel. Yet I'm wondering if BTRFS guys don't have a separate backup - which is then 4x? For my oS:TW VMs, I simply use the snapshots of the virtualization as backup before any updates. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org