[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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 <ad%netbsd.org@localhost>
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
(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:
VREG/VDIR: indirect blocks, to track per-inode space allocation
VBLK: dirty blocks for a block device
Others: not used
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. :-)
Main Index |
Thread Index |