Date: Sat, 14 Mar 2015 11:36:41 -0500 From: "Matthew D. Fuller" <fullermd@over-yonder.net> To: freebsd-fs@freebsd.org Subject: Troubles with zvol + BIO_DELETE Message-ID: <20150314163641.GK24274@over-yonder.net>
next in thread | raw e-mail | index | archive | help
In some GELI messing, we've found some bad behavior in sending DELETE's through to a backing zvol. After investigation, my best guess is that this is actually a bug in the zvol code. The requests come into zvol_geom_start(). In "normal" cases (e.g., when doing a newfs directly on the zvol), the bio's seem to go straight through to zvol_strategy(). However, when going through GELI, we hit the !THREAD_CAN_SLEEP() case, and so they get queued up. Then zvol_geom_worker() deals with them later. However, it doesn't know anything about BIO_DELETE; there's no handling at all. So at that point, the request just hangs around pending forever. I'm pretty sure it should just get send to zvol_strategy() the same as READ/WRITE do: Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c (revision 279210) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c (working copy) @@ -2775,6 +2775,7 @@ break; case BIO_READ: case BIO_WRITE: + case BIO_DELETE: zvol_strategy(bp); break; } -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150314163641.GK24274>