From owner-freebsd-hackers  Mon Nov 18 13:44:17 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id NAA14033
          for hackers-outgoing; Mon, 18 Nov 1996 13:44:17 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA14027
          for <hackers@FreeBSD.org>; Mon, 18 Nov 1996 13:44:13 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA07701; Mon, 18 Nov 1996 14:31:39 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199611182131.OAA07701@phaeton.artisoft.com>
Subject: Re: [Fwd: Device filesystem stumbling block]
To: julian@whistle.com (Julian Elischer)
Date: Mon, 18 Nov 1996 14:31:39 -0700 (MST)
Cc: hackers@FreeBSD.org
In-Reply-To: <3290B7AB.41C67EA6@whistle.com> from "Julian Elischer" at Nov 18, 96 11:23:23 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> the vnode in question is:
> $13 = {
>   v_flag = 8192, 
>   v_usecount = 2, 
>   v_writecount = 0, 
>   v_holdcnt = 3, 
>   v_lastr = 0, 
>   v_id = 1568, 
>   v_mount = 0xf0b34800, 
              **********		0xf0b34800
>   v_op = 0xf09c0a00, 
>   v_freelist = {
>     tqe_next = 0xf0ae1800, 
>     tqe_prev = 0xdeadb
                 *******       This is suspicious, but should not be fatal
>   }, 
>   v_mntvnodes = {
>     le_next = 0xf0ae1900, 
>     le_prev = 0xf0b34814
                **********		0xf0b34814

Last time I looked, sizeof(struct vnode) is larger than what you have
here:

	0xf0b34814 - 0xf0b34800 = 0x14 = 20 bytes

I would say your v_mntvnodes is corrupt, or this particular vnode is
corrupt.  Again, if it's the le_prev that's blown, then this should
not be fatal.


> and the buf in question is the buf holding the superblock for the
> filesystem. It is marked BUSY, but nothing is dealing with it so 
> getblk waits forever. for the life of me I can't figure out 
> what I need to add to devfs to make that block be handled.

Try adding the FORCECLOSE flag to the ffs_flushfiles() call in
ffs_unmount() in /sys/ufs/ffs/ffs_vfsops.c.

		flags |= FORCECLOSE;
	if (error = ffs_flushfiles(mp, flags, p))

If it "fixes" it, then it should be possible to get a better fix.


> I don't understand what is supposed to find it and do the write back
> that it is apparently waiting for.
> I've looked in the 4.4 book but unfortunatly it doesn't seem to cover
> this anywhere I can see. Certainly it lacks a clear diagram of
> the linking in of filesystem meta-data in the buffer system.
> I don't know  where this buffer is hung off.
> I guess I'm going to be single stepping through 'mount'
> tomorrow to try figure this out, but any hints in the meanwhile
> would be gratefully accepted..

One question occurs to me: is this the / FS?  If it is, then it will
never unbusy, since the devfs is mounted on it... right?


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.