From owner-freebsd-fs@FreeBSD.ORG Fri Apr 5 22:13:10 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E1FBEF6F for ; Fri, 5 Apr 2013 22:13:10 +0000 (UTC) (envelope-from lkchen@k-state.edu) Received: from ksu-out.merit.edu (ksu-out.merit.edu [207.75.117.132]) by mx1.freebsd.org (Postfix) with ESMTP id AE7A8FD4 for ; Fri, 5 Apr 2013 22:13:09 +0000 (UTC) X-Merit-ExtLoop1: 1 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAIBKX1HPS3TT/2dsb2JhbABIAxaCcDaDKb8IFnSCHwEBBSNWDAINGgINGQIdPAYTiBQMrzCJQ4kRBIEfjDaBWoIcgRMDp3uDJ4FXNQ X-IronPort-AV: E=Sophos;i="4.87,417,1363147200"; d="scan'208";a="212527876" X-MERIT-SOURCE: KSU Received: from ksu-sfpop-mailstore02.merit.edu ([207.75.116.211]) by sfpop-ironport07.merit.edu with ESMTP; 05 Apr 2013 18:09:27 -0400 Date: Fri, 5 Apr 2013 18:09:26 -0400 (EDT) From: "Lawrence K. Chen, P.Eng." To: Quartz Message-ID: <1964862508.3535448.1365199766508.JavaMail.root@k-state.edu> In-Reply-To: <514F5AD5.8000006@sneakertech.com> Subject: Re: ZFS: Failed pool causes system to hang MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.130.0.181] X-Mailer: Zimbra 7.2.2_GA_2852 (ZimbraWebClient - GC25 ([unknown])/7.2.2_GA_2852) Cc: FreeBSD FS 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: Fri, 05 Apr 2013 22:13:10 -0000 So, this thread seems to just stop....and can't see if it was resolved or not. Anyways, my input would be did you want long enough to see if the system will boot before declaring it hung? I've had my system crash at bad times, which has resulted in the appearance that the boot is hung...but its busy churning away.... Recently, I was destroying a large dataset on a raidz pool when the system had crashed. It seemed hung at trying to mount root....but it was churning away....and since I had it eventually booted after a similar incident. I left the system alone....and after almost 24 hours it finally did finally finish booting and everything was fine. Supposedly there's been a fix to make the destroy of large datasets faster...hopefully that'll make it in soon. OTOH, I had a system that corrupted the zpool so bad that it would panic when importing it....though I was able to import the pool read-only....so I was able to recover files and then start over again. The second time, it got corrupted that it wouldn't import under any condition. So, I had to start over from scratch. Eventually, tracked it down to a bad DIMM. ----- Original Message ----- > > > Sure, there are bugs that inhibit the ability to reboot from > > command-line. We shouldn't shrug them off, but we should also > > acknowledge that the software is very complicated, and rooting out > > such bugs takes time. Plus, this is a volunteer project. > > No, I'm not trying to say that I expect something as complicated as a > whole OS to be bug free, and I do well recognize that it's no one's > obligation to fix anything anyway.... I'm just saying that starting > an > argument about the remote-ness of the reboot is missing the point. > > > > Worst case, you have IP-addressable PDUs > > That's what we usually go with- guaranteed to work with any hardware. > That plus a vnc capable kvm. > -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator For: Enterprise Server Technologies (EST) -- & SafeZone Ally Snail: Computing and Telecommunications Services (CTS) Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102 Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkchen@ksu.edu Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library