broken-tree filesystem issue possibly fixed. It still thinks /srv exists when it doesn't and the built-in fs check thinks everything is fine, but whatever. At least it shouldn't randomly decide it has no free space anymore.
Timeline
Post
Remote status
Context
1
@phnt this is terrifying man. What good is a filesystem if you can't trust it with your data
Replies
19
@shinyoukai @phnt what's up with NetBSD's fs (UFS2 variant??) these days
@shinyoukai @feld The only BSD I would trust with my data is FreeBSD on ZFS. And maybe Dragonfly with Hammer. Except these two I don't think there's been many attempts to even have UFS journaled. You can do it with GEOM on FreeBSD somehow, but why bother when you have ZFS. Both {Open,Net}BSD have a habit of nuking filesystem on power failure.
@phnt @shinyoukai wdym? FreeBSD UFS has Soft Updates + Journaling
@phnt @shinyoukai it's still not as good as ZFS, even Kirk says to just use ZFS now
@feld @shinyoukai It is supported through GEOM and you have to do a little dance with partitions and gjournal. It's not configured by default I think which kind of sucks.
At least according to this documentation: https://docs.freebsd.org/en/articles/gjournal-desktop/
At least according to this documentation: https://docs.freebsd.org/en/articles/gjournal-desktop/
@phnt @feld @shinyoukai i'd run ZFS if it wasnt due to it being OOT and also the fact it doesn't use the linux VFS memory system (idk if it'll error out when doing memory intensive stuff)
@mischievoustomato @phnt @shinyoukai the ZFS ARC will give memory back to the OS, it's just not unified with the normal kernel VFS cache. Here's one of my servers
@feld @phnt @shinyoukai my laptop is a general pupose machine. I might consider ZFS when I upgrade my storage/laptop
@mischievoustomato @feld @shinyoukai You can change the Arc max size even on Linux. The only issue I'm aware of is that Arc isn't in memavailable.
https://github.com/openzfs/zfs/issues/10255
https://github.com/openzfs/zfs/issues/10255
@feld It definitely is, but after years of dealing with what it threw on me, dealing with this became a routine.
What if I tell you, that btrfs is designed to "not need" a filesystem consistency check and running btrfs check --repair is actually very discouraged and can make the situation much worse. Last time I used it two years ago, it crashed multiple times when trying to fix this exact issue I'm having with /srv currently (1). That time it would at least find the issue, but not this time. There's scrubbing, but that by default only checks file metadata which has a crc.
If you are wondering how can it have a reference to a directory that does not exist, this happens when you run out of "free space". Where "free space" is what btrfs thinks is free space instead of what it reports via everything like df. So you can have it report 12GB of free space, while writing a couple megabytes would fill the actual free space. Which is what happened to me for the second time in ~3 years. To fix it you have to do a dance of "rebalancing" which requires free space and effectively rewrites partially written allocated data chunks that then become available. (2)
(1) https://fluffytail.org/objects/a1a6b4a1-5864-4ae8-bd0e-3fd09062f762
(2) https://ohthehugemanatee.org/blog/2019/02/11/btrfs-out-of-space-emergency-response/