On Wed Sep 10, 2025 at 8:00 AM UTC, Stuart Henderson wrote: > I suggest newfs + recreating this filesystem from your backups. A crash > or power failure during active changes to the filesystem will often > result in filesystem damage and fsck isn't always able to fix the > problems.
Hi Stuart, I appreciate your reply. I haven't experienced an issue like that on Linux or FreeBSD (UFS or ZFS) ever. I've always had fscks able to at least make for a functional system, even if there is some loss. I am not sure what makes OpenBSD's FFS seem to be more fragile. I was able to fsck away and proceed. I did more writes and had another error. I ended up deleting the folder and trying again, and that system is stable. Still syncing the Monero and Bitcoin blockchains, very slow system. Now I had it again on another server. This is a remote dedicated server that I can have a KVM attached to. I was running Bitcoind and Monerod, both syncing. After some hours, I tried to SSH in and SSH was killing the connection after the handshake. I had a KVM attached to it, and there was no hang or error. I couldn't get to a login prompt, it only had messages about the devices attached. So I did a hard reset. Booting up, /var and /home were both corrupt and needed the fsck_ffs "F" fix to proceed. After this, it boots right into the same panic, which I'll attach as a PNG. Totally different hardware (x86_64, though) but same way to get there. I am surprised I don't hear more reports about this. I get that blockchain syncing is particularly active on disk, but it seems like this must happen somewhat often. I have not had this issue on my laptop after a number of hard resets. Do you know if there's a hardware-related trigger? Do 4K sectors or certain drive features make it any more or less likely? Thanks! -Henrich
