Re: kern/51447: nullfs seems to not delete files properly

[David Holland <dholland-bugs%netbsd.org@localhost>]

On Sat, Aug 27, 2016 at 11:30:02AM +0000, coypu%sdf.org@localhost wrote:
 > / is FFSv2 (no special mount options)
 > /usr/pkgsrc is mounted as nullfs at /netbsd6/usr/pkgsrc.
 > 
 > I ran:
 > # rm -rf /usr/pkgsrc/*/*/work
 > 
 > It appears some of my work directories were not deleted properly:
 > # cd /usr/pkgsrc/x11/qt5-qttools
 > # mkdir work
 > mkdir: work: No such file or directory

This should not happen -- if there's no name "work" there mkdir should
succeed, and otherwise you shouldn't get that message. (!)

I can't think of any way nullfs would affect that logic other than by
having bugs... and in fact I'm not even sure what those bugs would be.
nullfs should forward the VOP_MKDIR to ffs and that should not produce
ENOENT, and afterwards it should look up the result inode to make a
nullfs vnode and that should (AFAIK) not produce ENOENT either.
(Unless maybe it's an internal result that means something that was
expected to exist didn't?)

If it were losing the namei operation code such that ffs didn't
realize it was a CREATE operation, mkdir in nullfs wouldn't work at
all ever and that's not the case.

 > Running fsck -f /dev/rwd0a I see, among others:
 > [...]

Running fsck on a mounted volume doesn't generally produce useful
results, and in fact, doing

 > FREE BLK COUNT(S) WRONG IN SUPERBLK
 > SALVAGE? yes

and such will change the filesystem image behind the back of the
running fs code and is likely to corrupt the fs.

IOW, "don't do that", and if you did, probably best to unmount and do
a real fsck if you haven't already. :-/

-- 
David A. Holland
dholland%netbsd.org@localhost