Re: kern/41189: kernel panic xen dom0 using mke2fs & WAPBL

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

The following reply was made to PR kern/41189; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/41189: kernel panic xen dom0 using mke2fs & WAPBL
Date: Sun, 26 Apr 2009 05:04:55 +0000

 On Fri, Apr 17, 2009 at 08:55:02PM +0000, Andrew Doran wrote:
  >  Some background information. ffs hangs its dirty buffers in two places:
  >  
  >  - vp->v_dirtyblkhd
  >   
  >    VREG/VDIR: indirect blocks, to track per-inode space allocation
  >    VBLK: dirty blocks for a block device
  >    Others: not used
  >  
  >  - VTOI(vp)->i_ump->um_devvp->v_dirtyblkhd
  >  
  >    All other metadata, e.g. on-disk inodes.
  >  
  >  Since block devices don't have indirect blocks, there shouldn't be a clash.
  >  The whole thing is a big mess. We could fix a slew of bugs once and for all
  >  with devfs. It would greatly simplify this crud.
 
 Realistically devfs won't change the real problem (confusing whether
 um_devvp belongs to the fs mounted on it or the fs it sits on) but
 just replace wapbl-related issues with comparable devfs-related
 issues.
 
 The real fix is to change the buffer cache indexing scheme. Right now
 the buffer cache is indexed by vnode and offset; it should be indexed
 by filesystem (that is, struct mount), vnode or inode number, and
 offset. This should use a reserved inode number or vnode pointer for
 whole-fs buffers; and whole-fs buffers should be getting queued in the
 mount structure, not any vnode.
 
 Then at the cost of what should be only a small amount of new code
 (but a lot of interface changes) the potential for confusion will go
 away permanently, and we can change the name of um_devvp so as to hunt
 down and kill all further misuses of it.
 
  >  In the meantime I am going to crack open a beer. :-)
 
 wise choice. :-)
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost