From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 17:57:09 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BEA916A417 for ; Thu, 30 Aug 2007 17:57:09 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 1723413C46B for ; Thu, 30 Aug 2007 17:57:08 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by ug-out-1314.google.com with SMTP id a2so237143ugf for ; Thu, 30 Aug 2007 10:56:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:user-agent; b=AO9o+hkbbNrShWazycm5Yt7Z8HI0SyMnx/Erkaw2QKJFuWJjdOSUnCvfgNQjj5gw1rPj4Ynps2tintpdU8tP2GDqhcB0BtxvG6jhtPXh9ue1iVbKdfwugQOWvY92S87xmghiLuzW0fEsDmhh1f+f/Tx8Q+y70gLLrCaRcqNXuR4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:user-agent; b=ti+UHG6Qv1XxQd+3F+E7yRmt4LJXL6QhPhVcdkFZRcFUKiPNhbJXwmpqcawuU+gAW/1lFIPQj1Ydvd9ccTBzK4Himq6aIIqwO3CFAAPlay8IFUu/8qAYluVxy0AAH+LT3Q8vwAxkMcawSERDIEs1N6uSHsk0rmTjRM63uVOX6hw= Received: by 10.78.130.6 with SMTP id c6mr551361hud.1188496612934; Thu, 30 Aug 2007 10:56:52 -0700 (PDT) Received: from roadrunner.spoerlein.net ( [85.180.190.153]) by mx.google.com with ESMTPS id 37sm1017631hub.2007.08.30.10.56.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Aug 2007 10:56:52 -0700 (PDT) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.1/8.14.1) with ESMTP id l7UHumjb002213 for ; Thu, 30 Aug 2007 19:56:48 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.spoerlein.net (8.14.1/8.14.1/Submit) id l7UHum0I002212 for current@freebsd.org; Thu, 30 Aug 2007 19:56:48 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Thu, 30 Aug 2007 19:56:48 +0200 From: Ulrich Spoerlein To: current@freebsd.org Message-ID: <20070830175648.GA1453@roadrunner.spoerlein.net> Mail-Followup-To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: panic: geli vs. zfs scrubbing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2007 17:57:09 -0000 Hi -current, I found a reproducible panic with GELI's 'detach on close' feature interfering with 'zpool scrub' of an eli provider. root@roadrunner: ~# zpool status pool: tank state: ONLINE scrub: scrub completed with 0 errors on Thu Aug 30 19:35:14 2007 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 ad0s4d.eli ONLINE 0 0 0 Where /usr and /var are on tank (among others). This setup is working just fine (module buffer cache anomalies). Anyway, I issued a 'zpool scrub tank' just for kicks, here's the panic (hand transcribed): # zpool scrub tank GEOM_ELI: Detached ad0s4d.eli on last close. panic: function g_eli_orphan_spoil_assert() called for ad0s4d.eli panic() g_eli_orphan_spoil_assert() g_spoil_event() g_run_events() g_event_procbody() The workaround is to set geli_autodetach=NO in /etc/rc.conf. After that, scrubbing is doing its thing. Would be nice to have something like geli detach -l, which turns *off* the close-on-detach flag for an already attached provider. That way, you can use it as a one-shot workaround. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt.