Project

General

Profile

Actions

Bug #1286

closed

msdosfs crashes (when using rsync?)

Added by corecode almost 13 years ago. Updated over 12 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

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)

Actions #1

Updated by nthery over 12 years ago

2009/2/18 Simon 'corecode' Schubert (via DragonFly issue tracker)
<>:

New submission from Simon 'corecode' Schubert <>:

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.

Actions #2

Updated by nthery over 12 years ago

I committed a fix (629f33a733bba046a296b5f1dfa4ef45bc388cb4) that
fixes this case and hopefully the originally reported one.

Actions

Also available in: Atom PDF