Date: Sat, 5 Dec 2009 14:33:11 +0000 (UTC) From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs vdev_geom.c zvol.c Message-ID: <200912051433.nB5EXWt4029755@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
pjd 2009-12-05 14:33:11 UTC
FreeBSD src repository
Modified files:
sys/cddl/contrib/opensolaris/uts/common/fs/zfs vdev_geom.c
zvol.c
Log:
SVN rev 200126 on 2009-12-05 14:33:11Z by pjd
Fix deadlock when ZVOLs are present and we are replacing dead component or
calling scrub when pool is in a degraded state. It will try to taste ZVOLs,
which will lead to deadlock, as ZVOL will try to acquire the same locks as
replace/scrub is holding already.
We can't simply skip provider based on their GEOM class, because ZVOL can have
providers build on top of it and we need to skip those as well.
We do it by asking for ZFS::iszvol attribute. Any ZVOL-based provider will give
us positive answer and we have to skip those providers.
This way we remove possibility to create ZFS pools on top of ZVOLs, but it is
not very useful anyway.
I believe deadlock is still possible in some very complex situations like when
we have MD provider on top of UFS file on top of ZVOL. When we try to replace
dead component in the pool mentioned ZVOL is based on, there might be a
deadlock when ZFS will try to taste MD provider. There is no easy way to detect
that, but it isn't very common.
MFC after: 1 week
Revision Changes Path
1.15 +6 -1 src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
1.10 +4 -1 src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200912051433.nB5EXWt4029755>