Bug #1286
closed
msdosfs crashes (when using rsync?)
0%
Description
Just now, twice, also on a fsck'ed system:
panic: msdosfs_reinsert: insertion failed 16
#2 0xc0195c35 in panic (fmt=0xe390b2c0 "msdosfs_reinsert: insertion failed %d")
at /usr/src/sys/kern/kern_shutdown.c:800
bootopt = 256
newpanic = 1
ap = 0xe3774a20 "\020"
buf = "msdosfs_reinsert: insertion failed 16", '\0' <repeats 218 times>
#3 0xe3903a55 in msdosfs_reinsert (ip=0xe2bcd8a8, new_dirclust=994439,
new_diroffset=224)
at /usr/src/sys/vfs/msdosfs/msdosfs_denode.c:225
ilock = {tr_tok = 0xe390cd1c, tr_next = 0x0, tr_state = 1}
error = 0
#4 0xe39093a0 in msdosfs_rename (ap=0xe3774acc) at
/usr/src/sys/vfs/msdosfs/msdosfs_vnops.c:1274
new_dirclust = 994439
new_diroffset = 0
tdvp = (struct vnode *) 0xe7d3d968
fvp = (struct vnode *) 0xe3a21ee8
fdvp = (struct vnode *) 0xe7d3d968
tvp = (struct vnode *) 0x0
tcnp = (struct componentname *) 0xe3774b3c
fcnp = (struct componentname *) 0xe3774b5c
ip = (struct denode *) 0xe2bcd8a8
xp = (struct denode *) 0x0
dp = (struct denode *) 0xe2a2ad30
zp = (struct denode *) 0xe2a2ad30
toname = "ALBUMA~1JPG"
oldname = "ALBUMA~1RST"
from_diroffset = 1088
to_diroffset = 224
doingdirectory = 0
cn = <value optimized out>
pmp = (struct msdosfsmount *) 0xe32e91c8
dotdotp = <value optimized out>
bp = <value optimized out>
happend when calling rsync -aPv /dir/on/hammer /dir/on/msdosfs
crashdump available on request (mega huge one)
Updated by nthery over 15 years ago
2009/2/18 Simon 'corecode' Schubert (via DragonFly issue tracker)
<sinknull@crater.dragonflybsd.org>:
New submission from Simon 'corecode' Schubert <corecode@fs.ei.tum.de>:
Just now, twice, also on a fsck'ed system:
panic: msdosfs_reinsert: insertion failed 16
[...]
happend when calling rsync -aPv /dir/on/hammer /dir/on/msdosfs
crashdump available on request (mega huge one)
I think I root caused the bug and can reproduce it with the following steps:
mkdir d
cd d
touch f1
touch f2
from another term to keep a vnode on f2: vi f2
rm f2
mv f1 f3
f2 is the last entry in d. When it is deleted, the entry is free'd
but the denode associated with f2 stays in the dehashtbl[].
When f1 is renamed, msdosfs_lookup() looks for a new dir entry to move
it too(*) and finds the one previously used by f2.
When msdosfs_rename() reinserts f1's denode in the hash table, the
assertion fires because f2's denode is still there.
So the assertion I added some months ago is incorrect (but ignoring
the error was incorrect too).
I'm trying to come up with a fix...
(*) Contrary to what is stated in comment before msdosfs_rename(),
when simply renaming a file (no move), the original dir entry is not
reused. Instead a new one is allocated.
Updated by nthery over 15 years ago
I committed a fix (629f33a733bba046a296b5f1dfa4ef45bc388cb4) that
fixes this case and hopefully the originally reported one.