NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

On Apr 17,  8:55pm, (Andrew Doran) wrote:
-- Subject: Re: kern/41189: kernel panic xen dom0 using mke2fs & WAPBL

| The following reply was made to PR kern/41189; it has been noted by GNATS.
| From: Andrew Doran <>
| To:
| Cc: 
| Subject: Re: kern/41189: kernel panic xen dom0 using mke2fs & WAPBL
| Date: Fri, 17 Apr 2009 20:51:04 +0000
|  I don't know exactly what is happening in this case but there are at least
|  two issues that I see. Ok so ffs_full_fsync() is called for the vnode
|  representing /dev/sd0m:
|  (1) WAPBL processing should happen on this vnode, because the corresponding
|  inode is from a logging file system. However it represents a block device,
|  and so the call to wapbl_vptomp() ignores the important fact that it's from
|  a logging FS and returns NULL. We skip the WAPBL block.
|  (2) Since we are not doing the logging update in ffs_full_sync(), we descend
|  into the regular UFS case. This flushes any delayed writes resulting from
|  block I/O from userspace (or a mounted file system) to the device. This
|  happens correctly. Note that if (1) is fixed naively, this will cease to
|  happen. In theory this should flush the buffers for spec_close(). Once this
|  is done, we incorrectly do the inode update as if there was no logging.
|  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. In the meantime I am going
|  to crack open a beer. :-)

I think that there are differences in the way that the wait or no wait flag
is computed in many places and I believe that they should be consistent. Like:

error = ffs_update(vp, NULL, NULL,
    (ap->a_flags & FSYNC_WAIT) ? UPDATE_WAIT : 0);

error = ffs_update(vp, NULL, NULL,
    ((ap->a_flags & (FSYNC_WAIT | FSYNC_DATAONLY)) == FSYNC_WAIT)
    ? UPDATE_WAIT : 0);


Home | Main Index | Thread Index | Old Index