Date: Sat, 14 Mar 2015 17:37:07 +0000 From: Steven Hartland <killing@multiplay.co.uk> To: freebsd-fs@freebsd.org Subject: Re: Troubles with zvol + BIO_DELETE Message-ID: <550471C3.7010409@multiplay.co.uk> In-Reply-To: <20150314163641.GK24274@over-yonder.net> References: <20150314163641.GK24274@over-yonder.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14/03/2015 16:36, Matthew D. Fuller wrote: > 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; > } This is correct I've just committed the fix with a slight change so other bio types don't get lost too: https://svnweb.freebsd.org/changeset/base/279996 Its scheduled for MFC in two weeks. Thanks for this Matthew :) Regards Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?550471C3.7010409>