From owner-freebsd-fs@FreeBSD.ORG Wed Feb 6 20:03:08 2013 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 12EBDD38; Wed, 6 Feb 2013 20:03:08 +0000 (UTC) (envelope-from jhein@symmetricom.us) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id C1721704; Wed, 6 Feb 2013 20:03:07 +0000 (UTC) Received: from bosvc206-1.symmetricom.us (bosvc206-1.symmetricom.us [206.168.13.145]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r16K36GQ019014; Wed, 6 Feb 2013 13:03:06 -0700 (MST) (envelope-from jhein@symmetricom.us) Received: from bosvc206-1.symmetricom.us (localhost [127.0.0.1]) by bosvc206-1.symmetricom.us (8.14.5/8.14.5) with ESMTP id r16K36Ns046063; Wed, 6 Feb 2013 13:03:06 -0700 (MST) (envelope-from jhein@bosvc206-1.symmetricom.us) Received: (from jhein@localhost) by bosvc206-1.symmetricom.us (8.14.6/8.14.6/Submit) id r16K35Nf046062; Wed, 6 Feb 2013 13:03:05 -0700 (MST) (envelope-from jhein) Date: Wed, 6 Feb 2013 13:03:05 -0700 (MST) Message-Id: <201302062003.r16K35Nf046062@bosvc206-1.symmetricom.us> To: FreeBSD-gnats-submit@freebsd.org Subject: operations on readonly zpool hang From: John Hein X-send-pr-version: 3.114 X-GNATS-Notify: Cc: fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 20:03:08 -0000 >Submitter-Id: current-users >Originator: John Hein >Organization: >Confidential: no >Synopsis: operations on readonly zpool hang >Severity: serious >Priority: medium >Category: kern >Class: sw-bug >Release: >Environment: recent 8-stable, 9-stable; noticed on both i386 & amd64 >Description: On 9-stable & 8-stable, zfs/zpool operations hang when trying to work on a readonly pool. I've tried 'zfs set mountpoint' and 'zfs scrub' (the latter accidentally during overnight run of periodic with daily_scrub_zfs_enable=yes). See also https://forums.freebsd.org/showthread.php?t=35505&highlight=readonly+zpool which mentions a panic. I didn't get a panic (yet). Use case when this was noticed: replace old pool with new, setting the new pool to have the old pool's mountpoint (to avoid changing all nfs clients). I think zfs should refuse the operation if readonly is a problem. What I really wanted was for the data to be readonly, but not the zfs metadata (i.e., "_mostly_ readonly"). But I can see how disallowing metadata ops on a readonly pool makes sense. >How-To-Repeat: cd /tmp dd if=/dev/zero bs=1m count=100 > ! z0 dd if=/dev/zero bs=1m count=100 > ! z1 sudo mdconfig -f z0 sudo mdconfig -f z1 sudo zpool create -m /tmp/ztmp ztmp mirror /dev/md0 /dev/md1 sudo zpool export ztmp sudo zpool import -o readonly=on ztmp sudo zfs set mountpoint=/tmp/ztmpnew ztmp ... hangs here In another window... % ps -ww -ax -o pid,ppid,%cpu,%mem,vsz,rss,wchan,stat,lstart,time,command | egrep 'zfs|PID' PID PPID %CPU %MEM VSZ RSS WCHAN STAT STARTED TIME COMMAND 45377 0 0.0 0.0 0 32 l2arc_fe DL Wed Feb 6 12:38:30 2013 0:00.01 [zfskern] 45674 1 0.0 0.3 44460 3256 select I Wed Feb 6 12:40:54 2013 0:00.01 sudo zfs set mountpoint=/tmp/z\ tmpnew ztmp 45687 45674 0.0 0.3 33488 3064 tx->tx_s D Wed Feb 6 12:40:54 2013 0:00.00 zfs set mountpoint=/tmp/ztmpne\ w ztmp % sudo procstat -k 45674 45687 PID TID COMM TDNAME KSTACK 45674 100106 sudo - mi_switch sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdw\ ait kern_select sys_select amd64_syscall Xfast_syscall 45687 100098 zfs - mi_switch sleepq_wait _cv_wait txg_wait_synced dsl_sync_task_group\ _wait dsl_sync_task_do dsl_props_set zfs_set_prop_nvlist zfs_ioc_set_prop zfsdev_ioctl devfs_ioctl_f kern_ioctl s\ ys_ioctl amd64_syscall Xfast_syscall >Fix: