Date: Tue, 19 Jul 2016 10:06:34 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 93942] [vfs] [patch] panic: ufs_dirbad: bad dir (patch from DragonFly) Message-ID: <bug-93942-3630-220CacJbm3@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-93942-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-93942-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=3D93942 Konstantin Belousov <kib@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kib@FreeBSD.org --- Comment #12 from Konstantin Belousov <kib@FreeBSD.org> --- (In reply to rdarbha from comment #11) Do you understand that your question contains the intrinsic contradiction ? Anyway, I looked at the Matt' patches. The vfs_cluster changes seems to be irrelevant, we start io (and perform SU-related rollbacks) in ffs_geom_strategy() which is executed after the cluster is fully constructed and validated. Similarly, we assert that there is no dandling dependencies when B_NOCACHE buffer is thrown away in brelse(). So I think that these bi= ts are not (directly) relevant to us. The interesting stuff is vnode vm_object size handling for directories. Th= is is the right thing to do, but I doubt that we would have issues with the present order as far as vnode is not unlocked between buffer allocation and pager resizing. Still it is better to do it right, patch is attached. If you have dirbad panics, I would first check your hardware and verified integrity of other files on the same volume. If you have canonical copy of= the data, say system distribution disk which was used to install, compare the checksums of regular files. --=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-93942-3630-220CacJbm3>