From owner-freebsd-current@FreeBSD.ORG Mon Feb 9 09:04:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6A4E106567F for ; Mon, 9 Feb 2009 09:04:30 +0000 (UTC) (envelope-from michael.gusek@web.de) Received: from fmmailgate02.web.de (fmmailgate02.web.de [217.72.192.227]) by mx1.freebsd.org (Postfix) with ESMTP id 7881C8FC0C for ; Mon, 9 Feb 2009 09:04:30 +0000 (UTC) (envelope-from michael.gusek@web.de) Received: from smtp06.web.de (fmsmtp06.dlan.cinetic.de [172.20.5.172]) by fmmailgate02.web.de (Postfix) with ESMTP id 1226FFA28D09 for ; Mon, 9 Feb 2009 10:04:29 +0100 (CET) Received: from [83.236.167.154] (helo=patmos.vanguard.de) by smtp06.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #277) id 1LWS44-00068S-00 for freebsd-current@freebsd.org; Mon, 09 Feb 2009 10:04:28 +0100 Message-ID: <498FF19C.7000303@web.de> Date: Mon, 09 Feb 2009 10:04:28 +0100 From: Michael Gusek User-Agent: Thunderbird 2.0.0.7pre (X11/20090206) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <200902051224.34442.michael.gusek@web.de> <20090206232327.GA19383@hyperion.scode.org> <498D6824.8060303@web.de> In-Reply-To: <498D6824.8060303@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: michael.gusek@web.de X-Sender: michael.gusek@web.de X-Provags-ID: V01U2FsdGVkX19DBks+LOZfquPG0IHZKsYUL/oPsfPuKdcOtdfw 6o/yj5pMI8bwOAulyiASQhbeGyjpuSMfUthNotnwxJr48vbY0I sNTWsHDvY2Gubt4WlTDg== Subject: Re: zfs: allocating allocated segment 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: Mon, 09 Feb 2009 09:04:31 -0000 Michael Gusek schrieb: > Peter Schuller schrieb: >>> I'm running a File server with zfs, 64 Bit, 4 GB Ram and RELENG_7. >>> Two days ago i uploaded a file via ftp to the server and the server >>> is crashing. After reboot FreeBSD can't import the zfs-pool. There >>> is a kernel-message: >>> >>> panic: Solaris(panic): zfs: allocating allocated >>> segment(offset=123456... size=74) >>> >>> cpuid = 0 >>> Uptime: 14m22s >>> panic: bufwrite: buffer is not busy??? >>> >>> Now i try to import the zfs-pool with a recent 8.0-current but with >>> the same result. It's very important to me to access the pool, so >>> did you have some idea's ? >>> >> >> The ZFS panic is from space_map.c in space_map_add(), happening via >> zfs_panic_recover(). It in turn is affected by zfs_recover: >> >> /* >> * zfs_recover can be set to nonzero to attempt to recover >> from >> * otherwise-fatal errors, typically caused by on-disk corruption. >> When >> * set, calls to zfs_panic_recover() will turn into warning >> messages. >> */ >> >> Setting the vfs.zfs.recover loader variable to 1 might possibly >> help. However I have never tried using that option and I'm not >> familiar with the code, so I have no idea how safe it is. In >> particular since you then seem to be getting a secondary panic (the >> "buffer is not busy" which is from ffs_vfsops. >> >> On another note: >> >> http://www.google.com/search?client=opera&rls=en&q=zfs:+allocating+allocated+segment&sourceid=opera&ie=utf-8&oe=utf-8 >> >> >> indicates you're not the only person who has seen similar >> errors. Unfortunately I cannot offer any insight other than to suggest >> digging through the google results. >> >> Was the original crash, prior to the mount problem, purely a software >> crash or was there, for example, a power outtage? I'm wondering >> whether there is any particular reason to believe there was some >> hardware/firmware fault causing corruption. >> >> > Thank you for your response Petter, > > on Monday i will give vfs.zfs.recover a try. The original crash was > beeing a ftp upload. There was'nt a power outtage or another kernel > message, so i don't think it is an hardware issue. > > Regards, > > Michael So now i'm trying set vfs.zfs.recover to 1. But the kernel crashed with panic: solaris assert: sm->sm_space == space (0xxfceee400 == 0xfceefc00) file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c, line: 357 I't seems the zfs structure is corrupt ? And then, is there a chance to repair this ? Greetings, Michael