From owner-freebsd-hackers  Mon Nov 18 15:53:39 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id PAA23674
          for hackers-outgoing; Mon, 18 Nov 1996 15:53:39 -0800 (PST)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA23668
          for <hackers@FreeBSD.org>; Mon, 18 Nov 1996 15:53:32 -0800 (PST)
Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.2/8.8.2) with SMTP id PAA16957; Mon, 18 Nov 1996 15:44:45 -0800 (PST)
Message-ID: <3290F4E6.41C67EA6@whistle.com>
Date: Mon, 18 Nov 1996 15:44:38 -0800
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: Terry Lambert <terry@lambert.org>
CC: hackers@FreeBSD.org
Subject: Re: [Fwd: Device filesystem stumbling block]
References: <199611182131.OAA07701@phaeton.artisoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

Terry Lambert wrote:
> 
> > 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.

I don't think this is it, in fact I think that this may just be 
some invalid fields or something..
it doesn't seem to be related...

> 
> > 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.
maybe....
but I think it's because of cunfusion about which filesystem is suposed
to handle the work.

> 
> > 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?
no,
these are literally from the example I gave...

mount -t devfs devfs /mnt
mount /mnt/wd0e /data/mnt
unmount /data/mnt

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