Troubles with zvol + BIO_DELETE

Steven Hartland killing at multiplay.co.uk
Sat Mar 14 17:37:25 UTC 2015



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


More information about the freebsd-fs mailing list