Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Jul 1999 22:17:39 +0200
From:      Bjoern Fischer <bfischer@Techfak.Uni-Bielefeld.DE>
To:        freebsd-stable@freebsd.org
Subject:   interesting ffs dup alloc
Message-ID:  <19990714221739.A408@frolic.no-support.loc>

next in thread | raw e-mail | index | archive | help
Hello,

shortly our server (3.2-STABLE) paniced (ffs_valloc: dup alloc) while
s.o. was trying to create a directory on an NFS client. As I examined
the crashdump roughly I found that inode 91 was about to be allocated
for the new dir. But "lost+found" was already assigned to inode 91.
This "lost+found" directory was initially created by fsck. Just
randomness or a really strange thing?

Attached is an excerpt from a debugger session,
comments start with "***":

(kgdb) where
***[...] you won't need this...
#9  0xc01488cc in panic (fmt=3D0xc022586d "ffs_valloc: dup alloc")
    at ../../kern/kern_shutdown.c:444
#10 0xc01c773e in ffs_valloc (pvp=3D0xc5ed9900, mode=3D16877, cred=3D0xc0b1=
b384,=20
    vpp=3D0xc5e4ea8c) at ../../ufs/ffs/ffs_alloc.c:604
#11 0xc01d857e in ufs_mkdir (ap=3D0xc5e4ec00) at ../../ufs/ufs/ufs_vnops.c:=
1297
#12 0xc01d95d5 in ufs_vnoperate (ap=3D0xc5e4ec00)
    at ../../ufs/ufs/ufs_vnops.c:2299
#13 0xc019dccc in nfsrv_mkdir (nfsd=3D0xc0b1b300, slp=3D0xc09f3a00,=20
    procp=3D0xc5dfd860, mrq=3D0xc5e4ee2c) at vnode_if.h:611
#14 0xc01aba0c in nfssvc_nfsd (nsd=3D0xc5e4ee8c, argp=3D0x80719bc "", p=3D0=
xc5dfd860)
    at ../../nfs/nfs_syscalls.c:656
#15 0xc01ab309 in nfssvc (p=3D0xc5dfd860, uap=3D0xc5e4ef94)
    at ../../nfs/nfs_syscalls.c:342
#16 0xc0200b6c in syscall (frame=3D{tf_es =3D 39, tf_ds =3D 39, tf_edi =3D =
4,=20
      tf_esi =3D 0, tf_ebp =3D -1077944892, tf_isp =3D -974852124, tf_ebx =
=3D 0,=20
      tf_edx =3D -1077945296, tf_ecx =3D 0, tf_eax =3D 155, tf_trapno =3D 1=
2,=20
      tf_err =3D 2, tf_eip =3D 134518896, tf_cs =3D 31, tf_eflags =3D 646,=
=20
      tf_esp =3D -1077945288, tf_ss =3D 39}) at ../../i386/i386/trap.c:1100
#17 0xc01f6cbc in Xint0x80_syscall ()
#18 0x80480e9 in ?? ()
(kgdb) frame 10
#10 0xc01c773e in ffs_valloc (pvp=3D0xc5ed9900, mode=3D16877, cred=3D0xc0b1=
b384,=20
    vpp=3D0xc5e4ea8c) at ../../ufs/ffs/ffs_alloc.c:604
604                     panic("ffs_valloc: dup alloc");
(kgdb) print /o ip->i_din.di_mode
$9 =3D 041777
***ip->i_din.di_mode=3Dip->i_mode; this is drwxrwxrwt; mode of lost+found
(kgdb) print ip->i_number
$10 =3D 91
***this lost+found

Is it possible that fsck failed to create lost+found properly? It seems
like it doesn't use mkdir() for creation. BTW, yes I'm using
softupdates. Any hints where to look for more details? This is a
production server and I'm planning to delete and recreate lost+found
manually hoping it works as a workaround.

  Bj=F6rn Fischer

--=20
-----BEGIN GEEK CODE BLOCK-----
GCS d--(+) s++: a- C+++(-) UB++++OSI++++$ P+++(-) L+++(--) !E W- N+ o>+
K- !w !O !M !V  PS++  PE-  PGP++  t+++  !5 X++ tv- b+++ D++ G e+ h-- y+=20
------END GEEK CODE BLOCK------


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990714221739.A408>