Date: Fri, 01 Nov 2024 01:38:35 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 282449] UFS deadlock with install -S during freebsd-update Message-ID: <bug-282449-3630-HCbF9T2Gsv@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-282449-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-282449-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282449 --- Comment #6 from vfs-locking <Grau_Smue@md5hashing.net> --- (In reply to Mark Millard from comment #5) Notwithstanding that it looks like an I/O pileup, my impression is that the= re is something more. My previous 2 or 3 encounters on VBox were all on hosti= ng ZFS with sync=3Ddisabled, and there were no errors on the host side at those times since it continued other VMs and I/O. I only tried sync=3Dstandard t= his time because I was out of good ideas in attempts to reproduce. On the VPS encounter a few weeks ago, there could very well have been limit= ed I/O. But not zero. It was the VPS encounter that convinced me I was looki= ng at something other than a VBox bug, which is what I had previously thought = this was. I had changed from SCSI to AHCI in the guest, and even read about a f= ix in VBox that could have been my issue, until it happened again. >From there, it felt like a locking or race bug to me, that was happening because of the high volume of fsync() and rename() calls via install -S. I know those are hard to reproduce, but thats why I was willing to try repeatedly. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-282449-3630-HCbF9T2Gsv>