> What do you mean? Did you interrupt the reboot process (eg. repetitive ^C)? Otherwise the OS should flush everything properly. here’s my best guess: in my se

> What do you mean? Did you interrupt the reboot process (eg. repetitive ^C)? Otherwise the OS should flush everything properly. here’s my best guess: in my setup i have a host running a qemu vm and most of the interesting stuff happens inside the vm. originally that vm image was just 8 GB, but then i got a HDD to dedicate to it. with VM powered off, i partitioned the HDD and then dd’d the VM image onto it. then i booted the VM via KVM passthrough of /dev/sdb… it booted fine; i ran ‘df’ and noticed that i forgot to resize the fs to the HDD, so i ran resize2fs. 3 days later, i `shutdown` the VM and then `reboot`d the host. the host didn’t actually come back: the power light and activity lights were off. after 5 minutes of this i power-cycled at the wall socket. host came back up. vm wouldn’t boot. ran fsck from the rescue shell. now it booted, but no services were operational. since i couldn’t login to the vm (ssh broken + password logins had long been deactivated), i shutdown the vm and mounted its fs on the host. ‘df’ showed that the host thought the fs was only 8 GB in capacity. i don’t think it was outright disk corruption, because the poweroff wasn’t that messy (but i come from btrfs, which has handled like 20 power faults on me w/ zero issue: idk how solid EXT4 is to these things). my best guess is that somewhere along the way, the changes from resize2fs didn’t actually make it to disk, or were overrided with stale in-memory values. maybe when i updated the guest’s kernel some post-upgrade script did something to push the old fs size to disk somewhere. or maybe the host had the old 8 GB fs size cached and flushed that during shutdown/start. unfortunately i’m not sure i’ll ever know.