From owner-freebsd-fs@FreeBSD.ORG Fri Aug 31 12:09:40 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD1F51065676; Fri, 31 Aug 2012 12:09:40 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7CA9F8FC1C; Fri, 31 Aug 2012 12:09:40 +0000 (UTC) Received: from [10.4.0.166] ([149.6.120.133]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q7VC9V3b042859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 Aug 2012 05:09:33 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Marcel Moolenaar In-Reply-To: Date: Fri, 31 Aug 2012 13:09:40 +0100 Message-Id: <96DC4416-6CA5-45B4-B790-068797FAA2C6@xcllnt.net> References: To: Boris Astardzhiev X-Mailer: Apple Mail (2.1486) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, Grzegorz Bernacki Subject: Re: NANDFS: out of space panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 12:09:40 -0000 On Aug 22, 2012, at 4:34 PM, Boris Astardzhiev = wrote: > Now when I attempt to delete /mnt/file1234 I get a panic: > root@smartcpe:/mnt # rm file1234 > panic: bmap_truncate_mapping: error 28 when truncate at level 1 >=20 > KDB: enter: panic > [ thread pid 606 tid 100047 ] > Stopped at kdb_enter+0x48: ldrb r15, [r15, r15, ror r15]! > db> >=20 > So how do I solve this? It is easily reproduced following this = scenario > every time. > Up to this commit I've made the following minor changes so that I ran into this as well. There are 2 aspects here: 1. Currently errors pretty much result in panics by virtue of a compile-time option. This means that reasonable errors (i.e. errors that simply trigger recovery code or are being propagated upstream) also cause panics. 2. There's a real bug. For me it gives the following panic (by virtue of me changing the behaviour of point 1): nandfs_new_segment: cannot create segment error 1 create_segment: cannot create next segment nandfs_add_blocks: error:1 when creating segment nandfs_new_segment: cannot create segment error 1 create_segment: cannot create next segment nandfs_add_blocks: error:1 when creating segment nandfs_new_segment: cannot create segment error 1 create_segment: cannot create next segment nandfs_add_blocks: error:1 when creating segment nandfs_new_segment: cannot create segment error 1 create_segment: cannot create next segment nandfs_add_blocks: error:1 when creating segment nandfs_new_segment: cannot create segment error 1 create_segment: cannot create next segment nandfs_add_blocks: error:1 when creating segment nandfs_new_segment: cannot create segment error 1 create_segment: cannot create next segment nandfs_add_blocks: error:1 when creating segment nandfs_new_segment: cannot create segment error 1 create_segment: cannot create next segment nandfs_add_blocks: error:1 when creating segment nandfs_new_segment: cannot create segment error 1 create_segment: cannot create next segment nandfs_add_blocks: error:1 when creating segment nandfs_new_segment: cannot create segment error 1 create_segment: cannot create next segment nandfs_add_blocks: error:1 when creating segment nandfs_new_segment: cannot create segment error 1 create_segment: cannot create next segment nandfs_add_blocks: error:1 when creating segment nandfs_new_segment: cannot create segment error 1 create_segment: cannot create next segment nandfs_add_blocks: error:1 when creating segment nandfs_new_segment: cannot create segment error 1 create_segment: cannot create next segment nandfs_add_blocks: error:1 when creating segment nandfs_new_segment: cannot create segment error 1 create_segment: cannot create next segment nandfs_add_blocks: error:1 when creating segment nandfs_new_segment: cannot create segment error 1 create_segment: cannot create next segment lock order reversal: 1st 0xd944e60c bufwait (bufwait) @ kern/vfs_bio.c:1905 2nd 0xc501cd18 devfs (devfs) @ fs/nandfs/nandfs_segment.c:769 KDB: stack backtrace: db_trace_self_wrapper(c08fea97,746e656d,373a632e,a3936,0,...) at = db_trace_self_wrapper+0x26 kdb_backtrace(c06cadeb,c09024bc,c0b03d88,301,c46c5a88,...) at = kdb_backtrace+0x2a _witness_debugger(c09024bc,c501cd18,c08f5fd8,c4921b80,c08e785b,...) at = _witness_debugger+0x25 witness_checkorder(c501cd18,9,c08e7852,301,c501cd38,...) at = witness_checkorder+0x86f __lockmgr_args(c501cd18,80000,c501cd38,0,0,...) at __lockmgr_args+0x824 vop_stdlock(c46c5bbc,c08e76ed,c46c5b9c,c46c5b9c,c46c5bf8,...) at = vop_stdlock+0x62 VOP_LOCK1_APV(c0961780,c46c5bbc,100000,c4ffc480,c4b15000,...) at = VOP_LOCK1_APV+0xf3 nandfs_clean_segblocks(fee0,0,c46c5c6c,c46c5c6c,1,...) at = nandfs_clean_segblocks+0x48 clean_seginfo(c0962360,c46c5c6c,317a,0,0,...) at clean_seginfo+0x49 nandfs_segment_constructor(c4b1ec00,0,5c,c08ed1d5,1f4,...) at = nandfs_segment_constructor+0x5e5 nandfs_syncer(c4b1ec00,c46c5d08,c08f5110,3d8,c09b7520,...) at = nandfs_syncer+0x8f fork_exit(c05a63a0,c4b1ec00,c46c5d08) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xc46c5d40, ebp =3D 0 --- panic: brelse: not dirty cpuid =3D 0 KDB: enter: panic I haven't had the time to look into it in detail. Also: design documentation is missing right now, which does mean that there's a pretty steep curve for anyone who didn't write the file system to go in and fix any bugs. FYI, --=20 Marcel Moolenaar marcel@xcllnt.net