panic: handle_written_inodeblock: bad size

Jeremy Chadwick freebsd at jdc.parodius.com
Mon Jul 19 11:31:49 UTC 2010


On Mon, Jul 19, 2010 at 02:40:29AM -0400, Mikhail T. wrote:
> An 8.1-prerelease machine I have throws the panic in subject quite
> often. Does anyone care? Is this evidence of some filesystem
> corruption here, or a known problem that's (almost) solved already?
> 
> The stacks all look the same:
> 
>    panic: handle_written_inodeblock: bad size
>    ts_to_ct(1279145603.245753580) = [2010-07-14 22:13:23]
>    ...
>    #0  doadump () at pcpu.h:230
>    #1  0xc05be054 in boot (howto=260) at
>    /usr/src/sys/kern/kern_shutdown.c:416
>    #2  0xc05be261 in panic (fmt=Variable "fmt" is not available.
>    ) at /usr/src/sys/kern/kern_shutdown.c:590
>    #3  0xc07501b9 in softdep_disk_write_complete (bp=0xd81bcc30)
>         at /usr/src/sys/ufs/ffs/ffs_softdep.c:4615
>    #4  0xc062c386 in bufdone_finish (bp=0xd81bcc30) at buf.h:411
>    #5  0xc062c7bd in bufdone (bp=0xd81bcc30) at
>    /usr/src/sys/kern/vfs_bio.c:3275
>    #6  0xc0565bb5 in g_vfs_done (bip=0xc497e8c0)
>         at /usr/src/sys/geom/geom_vfs.c:97
>    #7  0xc0626db9 in biodone (bp=0xc497e8c0) at
>    /usr/src/sys/kern/vfs_bio.c:3110
>    #8  0xc056301f in g_io_schedule_up (tp=0xc4044000)
>         at /usr/src/sys/geom/geom_io.c:675
>    #9  0xc05633c8 in g_up_procbody () at /usr/src/sys/geom/geom_kern.c:95
>    #10 0xc0595f5f in fork_exit (callout=0xc0563360 <g_up_procbody>,
>    arg=0x0,
>         frame=0xe46a5d38) at /usr/src/sys/kern/kern_fork.c:844
>    #11 0xc07cf704 in fork_trampoline () at
>    /usr/src/sys/i386/i386/exception.s:273
> 
> Please, advise. Thanks!

If you boot the machine in single-user, and run fsck manually, are there
any errors?

Only thing I can think of off the top of my head: there's a known
situation (also applies to RELENG_7) where a background fsck doesn't
correct all errors after a system crash/unclean shutdown.  I mention
this because I see "softdep" in the above stack trace (usually refers to
softupdates).  I don't know if this got fixed, but the workaround is to
use background_fsck="no" in rc.conf.  Yes, after a crash this means you
have to wait for the entire fsck to run.

I can point you to some (old) discussions about it if need be.

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |



More information about the freebsd-stable mailing list