On 13 Dec, Don Lewis wrote: > On 12 Dec, Jeff Roberson wrote: > > >> fsync: giving up on dirty: 0xc4e18000: tag devfs, type VCHR, usecount 44, >> writecount 0, refcount 14, flags (VI_XLOCK|VV_OBJBUF), lock type devfs: EXCL >> (count 1) by thread 0xc20ff500 > > Why are we trying to reuse a vnode with a usecount of 44 and a refcount > of 14? What is thread 0xc20ff500 doing? Following up to myself ... It looks like we're trying to recycle this vnode because of the following sysinstall code, in distExtractTarball(): if (is_base && RunningAsInit && !Fake) { unmounted_dev = 1; unmount("/dev", MNT_FORCE); } else unmounted_dev = 0; I'm guessing that the purpose of this code is to unmount devfs from /dev so that when the base distribution is unpacked it can populate /dev from the tarball. This seems wrong, because it looks like the root file system is mounted on /mnt, and devfs is also mounted on /mnt/dev ... What happens if we forceably umount /dev while /dev/whatever holds a mounted file system? It looks like this is handled by vgonechrl(). It looks to me like vclean() is going to do some scary stuff to this vnode. BTW, I think the root vnode is the root of the md file system, not the root of the file system being populated by sysinstall. I don't know why there would be anything to sync at this point, though. I suspect that removing the above sysinstall code will fix the immediate problem, but there is still much I don't understand.Received on Sat Dec 13 2003 - 22:16:22 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:34 UTC