Re: panic when removing a file in current

[Johnny Billquist <bqt%softjar.se@localhost>]

On 2018-07-19 13:18, J. Hannken-Illjes wrote:
> On Thu, Jul 19, 2018 at 01:08:22PM +0200, Johnny Billquist wrote:
> > Hmm. That means I need to update user land, which can be a bit scary since it can make a rollback really hard.
> > And there is also a chicken and egg thing here. Installing a new user land can potentially mean removing files, which will trigger the panic.
> >
> > Is it really motivated with that panic? The system is running without issues on that same file system and NetBSD 7.
>
> You could backport this change to -7 fsck_ffs, the patch (attached) is small.

Some more updates. I decided to remove the panic call and do some tests 
with NetBSD 7 userland.

Ran the system in single user mode. File system clean and nice.
cp /netbsd /foo
rm /foo

Rebooting system, again into single user mode:

# fsck -f -y /
** /dev/rra0a
** File system is already clean
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
PARTIALLY ALLOCATED INODE I=47
CLEAR? yes

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? yes

SUMMARY INFORMATION BAD
SALVAGE? yes

BLK(S) MISSING IN BIT MAPS
SALVAGE? yes

5097 files, 131676 used, 122387 free (315 frags, 15259 blocks, 0.1% 
fragmentation)

***** FILE SYSTEM WAS MODIFIED *****


So it is an error created with NetBSD-8 and even detected with fsck from 
NetBSD-7 without any patching. Doing the same operation with NetBSD-7 
does not cause this corruption.
If I understand things right, this is that the disk blocks allocated to 
the file have not been released when the file is deleted, and the inode 
not cleared out?

Something have obviously changed here since NetBSD-7. I was trying to 
look a little at the code, and there is a truncate function called to 
trim the file down to 0 before deleting it, but I haven't had time to 
try and understand the code any better yet.

But maybe you, or someone else knows the innards of this better already 
and might know what the problem might be, or where.

Creating and working on files is fine. It's explicitly the deletion of 
files that cause the problem. And I've restored the panic call in 
ufs_inactive, since this was obviously a "good" panic.

  Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol