Re: panic when removing a file in current

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

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.

Like I said, these disks and file systems have been around a rather long time.

As for short files I believed that the data area in the indie was also used in a normal file for the first few bytes. Either way, when testing around this panic I can tell that creating a file with just a few bytes in it is not a problem. A can delete the file after creating. However, creating a larger file then triggers the panic when I delete the file again. So something is different on a really short file.

  Johnny

"J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost> skrev: (19 juli 2018 09:50:40 CEST)

 On 19. Jul 2018, at 03:54, Johnny Billquist <bqt%softjar.se@localhost> wrote:
 
 Anyone seen this, or know what it's about?

Great, it took 6 months to trigger my assertion ...

This panic probably means the file contains unallocated inodes that
were only partially zeroed.

Please run "fsck -f" on this file system and look for messages
like "PARTIALLY ALLOCATED INODE".

 On NetBSD/vax, with 8.99.22 from today.
 
 Removing any file that has disk blocks allocated to it:
 
 [ 653.3285523] ufs_inactive: unlinked ino 50313 on "/home" has non zero size 0 or blocks 1ac0 with allerror 0
 [ 653.3484633] panic: ufs_inactive: dirty filesystem?
 [ 653.3788284] cpu0: Begin traceback...
 [ 653.3984724] panic: ufs_inactive: dirty filesystem?
 [ 653.4090004] Stack traceback :
 [ 653.4231115]   Process is executing in user space.
 [ 653.4286045] cpu0: End traceback...
 Stopped in pid 39.1 (rm) at     netbsd:vpanic+0xc5:     pushl   $0
 
 
 If a file is small enough to have all the data in the inode itself, rm survives fine.

We never hold file data in inodes, only short sysmlinks.

 
  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

--
J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.