Re: ffs_newvnode: inode has non zero blocks

[Andreas Gustafsson <gson%gson.org@localhost>]

coypu%SDF.ORG@localhost wrote:
> I'm pretty 'abusive' to my machine. unsurprisingly, I've managed to accumulate a problem:
> 
>   ffs_newvnode: ino=20681997 on /: gen 5ae8a721/5ae8a721 has non zero blocks 980 or size 0
>   panic: ffs_newvnode: dirty filesystem?

The TNF sparc testbed recently started panicing with a similar error in
every test run:

  sbin/resize_ffs/t_grow_swapped (445/663): 4 test cases
      grow_16M_v0_65536: ffs_newvnode: ino=45826 on /: gen 65327e67/65327e67 has non zero blocks 180 or size 0
  panic: ffs_newvnode: dirty filesystem?
  cpu0: Begin traceback...
  0x0(0xf04010b8, 0xf4538a50, 0xf04a3800, 0xf04a4400, 0xf04a45c0, 0x104) at netbsd:panic+0x20
  panic(0xf04010b8, 0xf03c39a0, 0x0, 0xb302, 0xf07578d4, 0xf047e000) at netbsd:ffs_newvnode+0x444
  ffs_newvnode(0xf0730000, 0xf0970328, 0x81a4, 0xf4538cb0, 0xf069cb28, 0xf0984810) at netbsd:vcache_new+0x5c
  vcache_new(0xf0730000, 0xf0970328, 0xf4538cb0, 0xf069cb28, 0xf4538b74, 0x0) at netbsd:ufs_makeinode+0x14
  ufs_makeinode(0xf4538cb0, 0xf0970328, 0xf096ef2c, 0xf4538dcc, 0xf4538de0, 0xf0926460) at netbsd:ufs_create+0x30
  ufs_create(0xf4538c3c, 0xfffffff8, 0x0, 0x0, 0xf096ef2c, 0xf0970328) at netbsd:VOP_CREATE+0x28
  VOP_CREATE(0xf0970328, 0xf4538dcc, 0xf4538de0, 0xf4538cb0, 0xf0002000, 0xf0785150) at netbsd:vn_open+0x24c
  vn_open(0x0, 0x602, 0x1a4, 0xf069cb28, 0xf0851000, 0xf4538db8) at netbsd:do_open+0x90
  do_open(0x0, 0x0, 0xf0785150, 0x602, 0x1a4, 0xf4538ec4) at netbsd:do_sys_openat+0x60
  do_sys_openat(0xf0aa05a0, 0xffffff9c, 0xeda08080, 0x601, 0x1a4, 0xf4538ec4) at netbsd:sys_open+0x18
  sys_open(0xf0aa05a0, 0xf4538f30, 0xf4538f28, 0xeda08080, 0x0, 0x169b04f) at netbsd:syscall+0x248
  syscall(0xc05, 0xf4538fb0, 0xedc06b58, 0x5, 0x4e, 0xf0aa05a0) at netbsd:memfault_sun4m+0x3f4
  cpu0: End traceback...

More logs at:

  http://releng.netbsd.org/b5reports/sparc/commits-2016.10.html#2016.10.30.19.33.49

The strange thing is that this problem seems to have started soon
after your report, not before it as I would expect if it were also the
cause of your crash.  The filesystems involved are all newly created
in each test run.
-- 
Andreas Gustafsson, gson%gson.org@localhost