Re: ZFS rollback snapshot general question

On 6/25/26 18:11, Kevin P. Neal wrote:
 > On Mon, Jun 22, 2026 at 12:57:23PM -0400, Bobb Shires wrote:
 >> Recently upgraded my 14.4 installation to 15.1 and something went 
very wrong, so I decided to rollback the snapshot the installer script 
made for me (THANK YOU).
 >>
 >> When I hit enter on the rollback command the screen went completely 
blank, there was some brief disk activity, and the keyboard was 
unresponsive (like no caps lock response etc).
 >>
 >> I waited a few minutes and hit the power button, then powered back 
on and... it worked! Back to 14.4
ZFS snapshots are nearly instant. ZFS rollbacks and snapshot deletions 
are not; time it takes depends how much difference needs to be properly 
accounted for.

 >> My question is, I'm thinking that's not the expected behavior and I 
did something wrong? How and when should the ifs rollback command be 
invoked, and what should I expect to see?
Rolling back to a snapshot removes everything that came after it 
(probably what you wanted). If you have ZFS boot environments and the 
boot menu enabled then you can select which boot environment you want to 
use and it switches you to the chosen state but does not blow away all 
states after it to do so.

You should invoke a ZFS snapshot rollback when you need to revert a 
dataset to a previous state and are okay with all newer changes to it 
being lost. Once complete, What you should see is any snapshots and data 
changes that were created after the snapshot you roll back should be 
gone. Like with backups it is wise to make sure files are not in use 
when changing files that are normally in use. For all datasets including 
what you booted from when the system is installed on ZFS it is wise to 
reboot into single user mode with `shutdown now` and then doing the 
rollback to minimize anything running or launching while you work. Once 
complete you would then want to reboot. It is also safe to do such 
operation when booted from separate media to avoid anything being in use.

Boot environments are created by taking a snapshot of one (=shallow boot 
environment) or several (=deep boot environment) ZFS datasets and then 
promoting those snapshots to clones which makes them both able to be 
edited. If you have a working boot environment, you can modify other 
boot environments at will without breaking the current one.

Assuming you have boot environments, you likely wanted to pick a 
different one at the boot menu and then destroy the broken one that 
would have normally booted when not changing it at the menu. There was a 
thread here recently about the issues with unintuitive naming but it 
comes down to you need to know which one is which to properly pick what 
to boot to and pick what to delete.

As as reminder, any data outside the boot environments datasets is not 
managed by them; a software rollback without rolling back other data 
files is not always compatible, particularly with many databases.

 >> I was logged in as me (regular user) and did su then zfs rollback. 
Thanks!
 >
 > You did a zfs rollback of the current root filesystem on a running 
system?
 > I'm not surprised it went badly. I'm not sure the kernel expects 
filesystems
 > that programs are currently running out of to blow away programs with no
 > way to page any required pages back in, for example.
 >
 > Normally when a running program, or indeed any open file, is deleted the
 > inode remains valid until the program ends/the file is closed. 
(That's why
 > the system call is "unlink()" and not "delete()".) A ZFS rollback would
 > blow away the inode. If that case isn't explicitly supported then it will
 > probably blow up on you.
 >
 > After a rollback of the root filesystem (and /usr), what should the 
kernel
 > do about all the running programs including /sbin/init (which has a PID
 > of 1)? A rollback would result in probably all running programs being
 > killed, but that leaves no program left to do anything including ask what
 > shell to use for a single user mode command line.
 >
 > Really, the rollback should have been blocked and not allowed.
You do have good points about issues to consider but with applying that 
same logic we should have to boot from separate media to upgrade too.