kern/175897: operations on readonly zpool hang

Andriy Gapon avg at FreeBSD.org
Sat Feb 9 17:10:02 UTC 2013


The following reply was made to PR kern/175897; it has been noted by GNATS.

From: Andriy Gapon <avg at FreeBSD.org>
To: John Hein <jhein at symmetricom.com>, Martin Matuska <mm at FreeBSD.org>,
        Pawel Jakub Dawidek <pjd at FreeBSD.org>
Cc: bug-followup at FreeBSD.org
Subject: Re: kern/175897: operations on readonly zpool hang
Date: Sat, 09 Feb 2013 19:06:55 +0200

 on 09/02/2013 17:53 John Hein said the following:
 > Here's the full procstat -kk -a output...
 
 John,
 
 thank you very much!
 
 This problem seems to be a weird omission in our ZFS port.
 
 This is how pool_status_check function looks in the last open source version of
 OpenSolaris:
 int
 pool_status_check(const char *name, zfs_ioc_namecheck_t type,
     zfs_ioc_poolcheck_t check)
 {
 	spa_t *spa;
 	int error;
 
 	ASSERT(type == POOL_NAME || type == DATASET_NAME);
 
 	if (check & POOL_CHECK_NONE)
 		return (0);
 
 	error = spa_open(name, &spa, FTAG);
 	if (error == 0) {
 		if ((check & POOL_CHECK_SUSPENDED) && spa_suspended(spa))
 			error = EAGAIN;
 		else if ((check & POOL_CHECK_READONLY) && !spa_writeable(spa))
 			error = EROFS;
 		spa_close(spa, FTAG);
 	}
 	return (error);
 }
 
 In current Illumos the code seems to be the same:
 http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/zfs_ioctl.c#pool_status_check
 
 Here is how the code looks in FreeBSD:
 int
 pool_status_check(const char *name, zfs_ioc_namecheck_t type)
 {
 	spa_t *spa;
 	int error;
 
 	ASSERT(type == POOL_NAME || type == DATASET_NAME);
 
 	error = spa_open(name, &spa, FTAG);
 	if (error == 0) {
 		if (spa_suspended(spa))
 			error = EAGAIN;
 		spa_close(spa, FTAG);
 	}
 	return (error);
 }
 
 
 The code seems to have been introduced in ZFSv15 import (commit r209962) and has
 not been changed/updated since then.
 
 The spa_writeable() check should have prevented the situation you are seeing.
 
 P.S.
 Exact cause of the hang is that txg threads are not started at all but the
 thread doing the ioctl waits on txg sync thread to do something.
 -- 
 Andriy Gapon


More information about the freebsd-bugs mailing list