Bernhard Voelker wrote:
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.
It's not even btrfs itself. It is snapper. Without that, the update would create the new file, but as the old one no longer has an directory entry pointing to it, it will be freed quite fast(*). But if you use snapshots, space cannot be freed until you remove that snapshot. (*) Check that when you delete a snapshot. On my TW it takes 10-30s at most until it is freed.
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).
TBH, I've never seen huge differences between df and btrfs fi df. If that makes the difference between a succeeded and a failed update the filesystem is already too small anyhow ;^>
On my home PC, I'm using a traditional EXT4, so I can easily live with 20G for "/" ...
So you don't use snapper. Deactivate it on btrfs, and you would be able to go with 20G, too, I'd say.
still I need the same size for regular backup space.
That's the point.
Yet I'm wondering if BTRFS guys don't have a separate backup - which is then 4x?
My server runs on a BTRFS RAID1, that would count as 4x I guess. For normal machines I don't really care much regarding the system. A reinstall is almost as fast as (or even faster than?) using a backup... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org