[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
PUFFS and existing file that get ENOENT
I am tracking a rare bug with perfused, where an existing file is
reported as unexistent. It happens after a few hours of usage, and it
happens only once: if I retry accessing the file, I am successful.
Adding traces in perfused while performing ktrace on the calling
process, I am now confident that perfused is not the component that
raises the ENOENT. Here is what I get in the ktrace:
14085 1 cc1 1326421055.211110998 CALL close(4)
14085 1 cc1 1326421055.214918302 RET close 0
14085 1 cc1 1326421055.215025195 CALL
14085 1 cc1 1326421055.215031533 NAMI
14085 1 cc1 1326421055.216282844 RET
open -1 errno 2 No such file or directory
In the PUFFS trace I collect in perfused, this open() only causes
LOOKUPs up to /manu/netbsd/usr, all successful, then nothing.
1326421055.215229913 LOOKUP "/" cn = "manu" error = 0
1326421055.215396312 LOOKUP "/manu" cn = "netbsd" error = 0
1326421055.215749931 LOOKUP "/manu/netbsd" cn = "usr" error = 0
That means the ENOENT is decided by the kernel on its own, perfused does
not produce it. The question is where can this come from? There are two
ENOENT occurences in sys/fs/puffs. One can happen at mount time, and I
ruled out the other in puffsop_flush() by adding a printf() that never
show up when the bug strikes.
There are also ENOENT in sys/dev/putter/putter.c, but they all have a
printf() that I would have seen, therefore it cannot come from there.
Hence I come to the conclusion that it may come from
sys/kern/vfs_lookup.c, but it is very unlikely that there is a bug there
that went unnoticed for other filesystems.
Anyone would have an idea of what can possibly be going on?
Main Index |
Thread Index |