[Bug 244048] mksnap_ffs hangs machine (12.1 regression over 11.3)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244048

--- Comment #14 from ml at netfence.it ---
I apologize for not being clear.
The problem is not deterministic: behaviour changes slightly from machine to
machine and even subsequent runs starting from the same VM snapshot can differ.


In comment 12 I was talking about the last situation I was able to achieve that
I think is interesting.

VirtualBox VM with two disk:
_ ada0 is the "system" disk (UFS SU+J);
_ ada1 is the "data" disk, i.e. the one I'm trying snapshots on (GELI+UFS SU,
no journal as it would prevent snapshotting).

The filesystem is clean: fsck finds no errors and everything works normally.
There are already 12 snapshots.

I can take one or two further snapshots (probably more, I didn't try): still
everything is fine.

However, if I *delete* an existing snapshot, trouble starts:
_ subsequent mksnap_ffs produces the deadlock I described;
_ trying to unmount the filesystem also hangs (but won't hang the whole
machine): ctrl-t may say it's in "secwr", like the above or in "bo_wwait" or in
"wdrain"; a LOR (ufs at vfs_mount.c:1349/devfs at ffs_vfsops.c:1610) may appear or
not;
_ even shutdown doesn't work properly: vnodes remaining count seems to rise and
decrease at the same time; it may reach 0, but will grow again.

What happens after an hard reset can vary: fsck -p in single user mode seems to
work and recover the situation; a background fsck is usually asking for
troubles, often resulting in a panic (dropping into DDB).



In the end I was perhaps looking at the wrong side of things: it might not be
mksnap_ffs that hangs the machine, but *deleting* a snapshot.
I'm not sure, though: I think in the past I've seen situations where it hanged
even without deleting, but I cannot reconstruct now.



Unfortunately https://reviews.freebsd.org/D28901 doesn't seem to help.
Next thing I'll do is try 13.0 (unless someone has a better suggestion).

-- 
You are receiving this mail because:
You are the assignee for the bug.