4 ms·

When did you run in any of these issues recently? These issues were a fact in the past but have been sorted out. df is not lying because the fs layer reports c

When did you run in any of these issues recently? These issues were a fact in the past but have been sorted out. df is not lying because the fs layer reports corrupt data but because of dedup and fs layering.

lproven 3y ago
I left SUSE close to the end of 2021, and I had had to reinstall my work laptop twice that year alone. I consider that recent enough to call it current. > df is not lying To me, that reads as "df isn't lying because $EXCUSES." I disagree. I don't care about excuses. I want a 100% accurate accounting of free space at all times via the standard xNix free-disk-space reporting command, and the same from the APIs that command uses so that applications can also get an accurate report of free space. If a filesystem cannot report free space reliably and accurately, then that filesystem is IMHO broken. Excuses do not exonerate the FS, and having other FS-specific commands that can report free space do not exonerate it. The `df` command must work, or the FS is broken. The primary point of Btrfs is that it is the only GPL snapshot-capable FS. The other stuff is gravy: it's a bonus. There are distros that use Btrfs that don't use snapshots, such as Fedora. Some Btrfs advocates use this to claim that the problems are not problematic. If the filesystem is of interest on the basis of feature $FOO, then "product $BAR does not exhibit this problem" is not an endorsement or a refutation if $BAR does not use feature $FOO. Btrfs RAID is broken in important ways, but that is not a deal-breaker because there are other perfectly good ways of obtaining that functionality using other parts of the Linux stack. If no feature or functionality is lost considering the OS and stack as a whole, then that isn't a problem. However, this remains serious and an issue. Additional problems include: • Poor integration into the overall industry-wide OS stack. Examples: - Existing commands do not work or give inconsistent results. - Duplication of functionality (e.g. overlap with `mdraid`) • Poor integration into specific vendors' OS stacks. Examples: - SUSE uses Btrfs heavily. But SUSE's `zypper` package manager is not integrated with its `snapper` tool. Zypper doesn't include snapshot space used by Snapper in its space estimation. Snapper is integrated with Btrfs; licence restrictions notwithstanding, I would be much reassured if Snapper supported other COW filesystems. (This has been attempted but I don't think anything shipped -- https://github.com/openSUSE/snapper/issues/145 https://github.com/openSUSE/snapper/issues/145 . I welcome correction on this!) The transactional features of SUSE's MicroOS family of distros rely heavily on Btrfs. As such, this lack of awareness of snapshot space utilization deeply worries me. I have raised this with SUSE management, but my concerns were dismissed. That worries me. What I want to see, for clarity, is for Zypper to look at what packages will be replaced, then ask the FS how big the consequent snapshot will be, and include that snapshot in its space estimation checks before beginning the operation so that at least the packaging operation can be safely aborted before starting. A better implementation would be to integrate package management with snapshot management so that older snapshots could be automatically pruned to ensure necessary space is made available, while also ensuring that a pre-operation snapshot is retained for rollback. That's harder but would work better. As it is, currently neither is attempted, and Zypper will start actions that result in filling the disk and thus trashing the FS, and there are no working repair tools to recover. - Red Hat removed Btrfs support from RHEL. As a result it has had to bodge transactional package management together by grafting Git-like functionality into OStree, then building two entirely new packaging systems around OStree, one for the OS itself and a different one for GUI-level packages. The latter is Flatpak, of course. This strikes me as prime evidence that: 1. Btrfs isn't ready. 2. Linux needs an in-kernel COW filesystem -- because much of the complexity of OStree, Flatpak, Nix/NixOS, Guix, SUSE's `transactional-update` commands and so on would be rendered unnecessary if it were in there.
- yencabulator 3y ago
  > To me, that reads as "df isn't lying because $EXCUSES." In that case, df also lies on ZFS, bcachefs, and LVM+snapshots. It's in the nature of thin allocation and CoW; if you ask two things sharing storage how much space they have available, that doesn't mean that space is available to both of them at the same time.
  - lproven 3y ago
    > df also lies on ZFS, bcachefs, and LVM+snapshots. It is possible. Got any examples? And more saliently do you have reports of disk corruption occurring as a result of falsely reported free space which was not in fact available? As has corrupted multiple Btrfs volumes for me, on multiple machines, in production, and with disastrous consequences and resultant need for complete system reinstallation?
    - yencabulator 3y ago
      You're moving the goalposts. You said > I want a 100% accurate accounting of free space at all times via the standard xNix free-disk-space reporting command You don't get that on many modern storage systems, because of thin provisioning. You don't get that even on old school unix if you ask separately in two different directories, and fail to account for whether they're on the same filesystem or not.
      - lproven 3y ago
        And again, since you seem not to have noticed: [[citation needed]] All xNix owners who can use the shell competently know that different directories may have different free-space counts. The problem is when the filesystem won't tell you a real free-space count at all.

lproven 3y ago

I left SUSE close to the end of 2021, and I had had to reinstall my work laptop twice that year alone. I consider that recent enough to call it current. > df is not lying To me, that reads as "df isn't lying because $EXCUSES." I disagree. I don't care about excuses. I want a 100% accurate accounting of free space at all times via the standard xNix free-disk-space reporting command, and the same from the APIs that command uses so that applications can also get an accurate report of free space. If a filesystem cannot report free space reliably and accurately, then that filesystem is IMHO broken. Excuses do not exonerate the FS, and having other FS-specific commands that can report free space do not exonerate it. The `df` command must work, or the FS is broken. The primary point of Btrfs is that it is the only GPL snapshot-capable FS. The other stuff is gravy: it's a bonus. There are distros that use Btrfs that don't use snapshots, such as Fedora. Some Btrfs advocates use this to claim that the problems are not problematic. If the filesystem is of interest on the basis of feature $FOO, then "product $BAR does not exhibit this problem" is not an endorsement or a refutation if $BAR does not use feature $FOO. Btrfs RAID is broken in important ways, but that is not a deal-breaker because there are other perfectly good ways of obtaining that functionality using other parts of the Linux stack. If no feature or functionality is lost considering the OS and stack as a whole, then that isn't a problem. However, this remains serious and an issue. Additional problems include: • Poor integration into the overall industry-wide OS stack. Examples: - Existing commands do not work or give inconsistent results. - Duplication of functionality (e.g. overlap with `mdraid`) • Poor integration into specific vendors' OS stacks. Examples: - SUSE uses Btrfs heavily. But SUSE's `zypper` package manager is not integrated with its `snapper` tool. Zypper doesn't include snapshot space used by Snapper in its space estimation. Snapper is integrated with Btrfs; licence restrictions notwithstanding, I would be much reassured if Snapper supported other COW filesystems. (This has been attempted but I don't think anything shipped -- https://github.com/openSUSE/snapper/issues/145 https://github.com/openSUSE/snapper/issues/145 . I welcome correction on this!) The transactional features of SUSE's MicroOS family of distros rely heavily on Btrfs. As such, this lack of awareness of snapshot space utilization deeply worries me. I have raised this with SUSE management, but my concerns were dismissed. That worries me. What I want to see, for clarity, is for Zypper to look at what packages will be replaced, then ask the FS how big the consequent snapshot will be, and include that snapshot in its space estimation checks before beginning the operation so that at least the packaging operation can be safely aborted before starting. A better implementation would be to integrate package management with snapshot management so that older snapshots could be automatically pruned to ensure necessary space is made available, while also ensuring that a pre-operation snapshot is retained for rollback. That's harder but would work better. As it is, currently neither is attempted, and Zypper will start actions that result in filling the disk and thus trashing the FS, and there are no working repair tools to recover. - Red Hat removed Btrfs support from RHEL. As a result it has had to bodge transactional package management together by grafting Git-like functionality into OStree, then building two entirely new packaging systems around OStree, one for the OS itself and a different one for GUI-level packages. The latter is Flatpak, of course. This strikes me as prime evidence that: 1. Btrfs isn't ready. 2. Linux needs an in-kernel COW filesystem -- because much of the complexity of OStree, Flatpak, Nix/NixOS, Guix, SUSE's `transactional-update` commands and so on would be rendered unnecessary if it were in there.

yencabulator 3y ago
> To me, that reads as "df isn't lying because $EXCUSES." In that case, df also lies on ZFS, bcachefs, and LVM+snapshots. It's in the nature of thin allocation and CoW; if you ask two things sharing storage how much space they have available, that doesn't mean that space is available to both of them at the same time.
- lproven 3y ago
  > df also lies on ZFS, bcachefs, and LVM+snapshots. It is possible. Got any examples? And more saliently do you have reports of disk corruption occurring as a result of falsely reported free space which was not in fact available? As has corrupted multiple Btrfs volumes for me, on multiple machines, in production, and with disastrous consequences and resultant need for complete system reinstallation?
  - yencabulator 3y ago
    You're moving the goalposts. You said > I want a 100% accurate accounting of free space at all times via the standard xNix free-disk-space reporting command You don't get that on many modern storage systems, because of thin provisioning. You don't get that even on old school unix if you ask separately in two different directories, and fail to account for whether they're on the same filesystem or not.
    - lproven 3y ago
      And again, since you seem not to have noticed: [[citation needed]] All xNix owners who can use the shell competently know that different directories may have different free-space counts. The problem is when the filesystem won't tell you a real free-space count at all.