From owner-freebsd-fs@FreeBSD.ORG Sun Mar 24 18:26:19 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B72D6770 for ; Sun, 24 Mar 2013 18:26:19 +0000 (UTC) (envelope-from quartz@sneakertech.com) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id 5E059DC4 for ; Sun, 24 Mar 2013 18:26:18 +0000 (UTC) Received: (qmail 84276 invoked by uid 0); 24 Mar 2013 18:26:10 -0000 Received: from 173.48.104.62 (HELO ?10.2.2.1?) (173.48.104.62) by relay01.pair.com with SMTP; 24 Mar 2013 18:26:10 -0000 X-pair-Authenticated: 173.48.104.62 Message-ID: <514F4542.7060100@sneakertech.com> Date: Sun, 24 Mar 2013 14:26:10 -0400 From: Quartz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: ZFS question References: <20130321044557.GA15977@icarus.home.lan> <514AA192.2090006@sneakertech.com> <20130321085304.GB16997@icarus.home.lan> <20130324153342.GA3687@icarus.home.lan> In-Reply-To: <20130324153342.GA3687@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-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: Sun, 24 Mar 2013 18:26:19 -0000 > I also confirmed that **reads** from the now-busted pool do block/wait > indefinitely Yeah, and that's the kicker. When my pool dies, I can't even check its status to figure out what the hell went wrong. >(for some reason people > think kill -9 will always cause a kernel to unlock/relinquish a thread, > which is not the case)). Oh believe me, from years of experience with linux/mac I wish it were true. >For whatever reason "ls -l /pool" did return > results, but I imagine these may be being returned from some caching > mechanism within the kernel (either VFS or ZFS ARC, not sure). I've noticed this too a couple times, but it only appears to happen for the top directory or so. Copy a folder with a lot of nested subfolders and then test with 'ls -R', that will kill it guaranteed. ______________________________________ it has a certain smooth-brained appeal