NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/51447: nullfs seems to not delete files properly
The following reply was made to PR kern/51447; it has been noted by GNATS.
From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/51447: nullfs seems to not delete files properly
Date: Mon, 5 Sep 2016 18:19:31 +0000
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
Home |
Main Index |
Thread Index |
Old Index