Date: Fri, 31 Aug 2012 13:09:40 +0100 From: Marcel Moolenaar <marcel@xcllnt.net> To: Boris Astardzhiev <boris.astardzhiev@gmail.com> Cc: freebsd-fs@freebsd.org, Grzegorz Bernacki <gber@freebsd.org> Subject: Re: NANDFS: out of space panic Message-ID: <96DC4416-6CA5-45B4-B790-068797FAA2C6@xcllnt.net> In-Reply-To: <CAP=KkTz3%2B7UbfBcW9D_8VHv-Rw7BxNyG5xiVFxG4L-Zq1skwJw@mail.gmail.com> References: <CAP=KkTz3%2B7UbfBcW9D_8VHv-Rw7BxNyG5xiVFxG4L-Zq1skwJw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 22, 2012, at 4:34 PM, Boris Astardzhiev =
<boris.astardzhiev@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?96DC4416-6CA5-45B4-B790-068797FAA2C6>