From owner-freebsd-fs Sun Oct 13 0:14:27 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F0CE37B401 for ; Sun, 13 Oct 2002 00:14:26 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DBED43E7B for ; Sun, 13 Oct 2002 00:14:25 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA18524; Sun, 13 Oct 2002 17:14:16 +1000 Date: Sun, 13 Oct 2002 17:24:35 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Peter Godman Cc: freebsd-fs@FreeBSD.ORG Subject: Re: ufs_update and waitfor flag In-Reply-To: Message-ID: <20021013163315.F21287-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 12 Oct 2002, Peter Godman wrote: > An application running on my system is doing basically: > > fd = open(file) > read(fd, ...) > fsync(fd) > close(fd) > > My root filesystem is mounted sync,noatime, but this sequence of > operations still results in a bwrite during fsync in ufs_update. This > seems to be the result of the following code in ufs_update: > > int > ffs_update(vp, waitfor) > struct vnode *vp; > int waitfor; > { > struct fs *fs; > struct buf *bp; > struct inode *ip; > int error; > > ufs_itimes(vp); > ip = VTOI(vp); > /* vvvvvvvvvvvv ?? */ > if ((ip->i_flag & IN_MODIFIED) == 0 && waitfor == 0) > return (0); > ip->i_flag &= ~(IN_LAZYMOD | IN_MODIFIED); > > ... > > The relevant part here is the "waitfor == 0" in the bailout check. Though > the flags on the inode do not indicate that the inode is modified, the > fact that we wish to wait for the operation to complete results a write > happening here that otherwise wouldn't have. Do other people read this > code the same way? Is this desired or expected behaviour? What would > happen if I commented out the check for waitfor == 0 at this > point? Anyone know why this check is there? Most likely I will modify > the application in question, but would like to know whether this code > should change too. The waitfor test was added in th first round of soft updates changes for reasons that I never completely understood. I vaguely remember that it is to get the DOINGSOFTDEP() case a little later in ffs_update() reached. I never liked this. It certainly seems to be wrong for fsync(2). ffs_fsync() is caled with waitfor set in that case, and we eventually write the inode even when it was perfectly clean. I'm fairly sure that you can remove the waitfor test in the !DOINGSOFTDEP() case. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Oct 14 5:36:23 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D678D37B401 for ; Mon, 14 Oct 2002 05:36:22 -0700 (PDT) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4614A43EA9 for ; Mon, 14 Oct 2002 05:36:22 -0700 (PDT) (envelope-from fwtk-req@tislabs.com) Received: by sentry.gw.tislabs.com; id IAA23288; Mon, 14 Oct 2002 08:36:16 -0400 (EDT) From: Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma023283; Mon, 14 Oct 02 12:35:19 GMT Received: (from daemon@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g9ECZNY20330 for fs@FreeBSD.org; Mon, 14 Oct 2002 08:35:23 -0400 (EDT) Date: Mon, 14 Oct 2002 08:35:23 -0400 (EDT) Message-Id: <200210141235.g9ECZNY20330@raven.gw.tislabs.com> Subject: Response to your fwtk-request request To: fs@FreeBSD.org Reply-To: fwtk-req-help@tislabs.com Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thank you for your interest in our Firewall Toolkit. You will find the current source in the following "hidden" directory on ftp.tislabs.com: /pub/firewalls/toolkit/dist/fwtk-571e72 Please change directory directly to the entire path provided. This directory will exist for at least 12 hours. If you are unable to download before this time period expires, you can send another request to fwtk-request@tislabs.com to receive a new path. If you are unable to establish a connection on ftp.tislabs.com, your IP address may not have the appropriate reverse mapping of address to hostname in the Domain Name System. As a security precaution, we do not allow connections to our ftp server that do not have this DNS information properly configured. Please contact your System Administrator in regard to correcting this. -NAI Labs To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Oct 14 11: 1: 3 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7422937B401 for ; Mon, 14 Oct 2002 11:01:02 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D7D143EAC for ; Mon, 14 Oct 2002 11:00:58 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id g9EI0wCo091640 for ; Mon, 14 Oct 2002 11:00:58 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id g9EI0wmS091634 for fs@freebsd.org; Mon, 14 Oct 2002 11:00:58 -0700 (PDT) Date: Mon, 14 Oct 2002 11:00:58 -0700 (PDT) Message-Id: <200210141800.g9EI0wmS091634@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: fs@FreeBSD.org Subject: Current problem reports assigned to you Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2000/10/06] kern/21807 fs [patches] Make System attribute correspon 1 problem total. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Oct 18 8:32:10 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9364F37B401; Fri, 18 Oct 2002 08:32:08 -0700 (PDT) Received: from ms3.mail2000.com.tw (ms3.mail2000.com.tw [211.72.252.187]) by mx1.FreeBSD.org (Postfix) with SMTP id 2F03943E4A; Fri, 18 Oct 2002 08:32:06 -0700 (PDT) (envelope-from sjs@mail2000.com.tw) Received: from 211.72.252.247 by ms3.mail2000.com.tw with Mail2000 ESMTP Server V2.71M(80288:0:AUTH_RELAY) Fri, 18 Oct 2002 23:32:00 +0800 (CST); (envelope-from ) Received: By OpenMail Mailer;Fri, 18 Oct 2002 23:31:59 +0800 (CST) From: "sjs" Reply-To: Subject: NAS via NFS crashes with vinvalbuf: flush failed Message-ID: <1034955118.86889.sjs@mail2000.com.tw> To: "" , "" Date: Fri, 18 Oct 2002 23:31:58 +0800 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I have two FreeBSD servers mount NetApp NAS via NFS and run under layer 4 switch to be redundant. I upgraded FreeBSD version from 4.2R to 4.6.1-RC2, the panic crash still happen very often. The messages I got from every crash are all the same which is about "vinvalbuf: flush failed". Once the server-1 crashes, server-2 will crash very soon. I guess there's some problems with accessing NFS files on NAS, so when server-1 crashes, server-2 keeps accessing the same file and then crahes, too. So is there any suggestion? Does it help to upgrade to 4.7R? PS: Both servers are with dual CPU with SMP enabled. I tried to turn off SMP, but it didn't help anything. Thanks! Best regards, Gareth ===========================Message attached===================== Oct 18 23:12:09 mail savecore: reboot after panic: vinvalbuf: flush failed (kgdb) bt #0 0xc01b0096 in dumpsys () #1 0xc01afe67 in boot () #2 0xc01b028c in poweroff_wait () #3 0xc01dc4c9 in vinvalbuf () #4 0xc023007c in nfs_vinvalbuf () #5 0xc0252ee9 in nfs_open () #6 0xc01e3943 in vn_open () #7 0xc01df848 in open () #8 0xc02e8aba in syscall2 () #9 0xc02da2f5 in Xint0x80_syscall () #10 0x804f62f in ?? () #11 0x804d9f8 in ?? () #12 0x804d2af in ?? () #13 0x804cac1 in ?? () #14 0x804adfc in ?? () #15 0x804a289 in ?? () To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Oct 18 10:16:49 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A324437B401; Fri, 18 Oct 2002 10:16:47 -0700 (PDT) Received: from blackhelicopters.org (geburah.blackhelicopters.org [209.69.178.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EF1F43E88; Fri, 18 Oct 2002 10:16:47 -0700 (PDT) (envelope-from mwlucas@blackhelicopters.org) Received: from blackhelicopters.org (mwlucas@localhost [127.0.0.1]) by blackhelicopters.org (8.12.5/8.12.5) with ESMTP id g9IHGfJ6056757; Fri, 18 Oct 2002 13:16:41 -0400 (EDT) (envelope-from mwlucas@blackhelicopters.org) Received: (from mwlucas@localhost) by blackhelicopters.org (8.12.5/8.12.5/Submit) id g9IHGe8I056756; Fri, 18 Oct 2002 13:16:40 -0400 (EDT) Date: Fri, 18 Oct 2002 13:16:40 -0400 From: Michael Lucas To: sjs Cc: freebsd-isp@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: NAS via NFS crashes with vinvalbuf: flush failed Message-ID: <20021018131640.A56728@blackhelicopters.org> References: <1034955118.86889.sjs@mail2000.com.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1034955118.86889.sjs@mail2000.com.tw>; from sjs@mail2000.com.tw on Fri, Oct 18, 2002 at 11:31:58PM +0800 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, Could you prepare a debugging kernel, so people can get a better idea of what happens? If you need some hints, take a look at: http://www.onlamp.com/pub/a/bsd/2002/03/21/Big_Scary_Daemons.html Various filesystem gurus will have a much better shot at figuring out the real problem if you have a dump on a debug kernel. Thanks! On Fri, Oct 18, 2002 at 11:31:58PM +0800, sjs wrote: > Hi, > > I have two FreeBSD servers mount NetApp NAS via NFS and run > under layer 4 switch to be redundant. I upgraded FreeBSD version > from 4.2R to 4.6.1-RC2, the panic crash still happen very often. > The messages I got from every crash are all the same which is about > "vinvalbuf: flush failed". Once the server-1 crashes, server-2 will > crash very soon. I guess there's some problems with accessing NFS > files on NAS, so when server-1 crashes, server-2 keeps accessing > the same file and then crahes, too. > > So is there any suggestion? Does it help to upgrade to 4.7R? > > PS: Both servers are with dual CPU with SMP enabled. I tried to > turn off SMP, but it didn't help anything. > > Thanks! > > Best regards, > Gareth > > ===========================Message attached===================== > > Oct 18 23:12:09 mail savecore: reboot after panic: vinvalbuf: flush failed > (kgdb) bt > #0 0xc01b0096 in dumpsys () > #1 0xc01afe67 in boot () > #2 0xc01b028c in poweroff_wait () > #3 0xc01dc4c9 in vinvalbuf () > #4 0xc023007c in nfs_vinvalbuf () > #5 0xc0252ee9 in nfs_open () > #6 0xc01e3943 in vn_open () > #7 0xc01df848 in open () > #8 0xc02e8aba in syscall2 () > #9 0xc02da2f5 in Xint0x80_syscall () > #10 0x804f62f in ?? () > #11 0x804d9f8 in ?? () > #12 0x804d2af in ?? () > #13 0x804cac1 in ?? () > #14 0x804adfc in ?? () > #15 0x804a289 in ?? () > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message -- Michael Lucas mwlucas@FreeBSD.org, mwlucas@BlackHelicopters.org http://www.oreillynet.com/pub/q/Big_Scary_Daemons Absolute BSD: http://www.AbsoluteBSD.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Oct 18 10:56:22 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B38637B401; Fri, 18 Oct 2002 10:56:19 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9918E43E88; Fri, 18 Oct 2002 10:56:18 -0700 (PDT) (envelope-from ps@mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 7A68DAE160; Fri, 18 Oct 2002 10:56:18 -0700 (PDT) Date: Fri, 18 Oct 2002 10:56:18 -0700 From: Paul Saab To: sjs Cc: freebsd-isp@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: NAS via NFS crashes with vinvalbuf: flush failed Message-ID: <20021018175618.GA97335@elvis.mu.org> References: <1034955118.86889.sjs@mail2000.com.tw> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline In-Reply-To: <1034955118.86889.sjs@mail2000.com.tw> User-Agent: Mutt/1.4i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline sjs (sjs@mail2000.com.tw) wrote: > Hi, > > I have two FreeBSD servers mount NetApp NAS via NFS and run > under layer 4 switch to be redundant. I upgraded FreeBSD version > from 4.2R to 4.6.1-RC2, the panic crash still happen very often. > The messages I got from every crash are all the same which is about > "vinvalbuf: flush failed". Once the server-1 crashes, server-2 will > crash very soon. I guess there's some problems with accessing NFS > files on NAS, so when server-1 crashes, server-2 keeps accessing > the same file and then crahes, too. Try this patch.. We've been running with it at Yahoo for about 3-4 weeks now. Its a hack, but something like this will eventually get committed to FreeBSD. --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xxx Index: kern/vfs_subr.c =========================================================================== --- kern/vfs_subr.c 2002/10/18 08:38:40 #23 +++ kern/vfs_subr.c 2002/10/18 08:38:40 @@ -781,6 +781,10 @@ struct buf *nbp, *blist; int s, error; vm_object_t object; + int retrycount; + + retrycount = 0; +restart: if (flags & V_SAVE) { s = splbio(); @@ -884,8 +888,30 @@ } simple_unlock(&vp->v_interlock); - if (!TAILQ_EMPTY(&vp->v_dirtyblkhd) || !TAILQ_EMPTY(&vp->v_cleanblkhd)) - panic("vinvalbuf: flush failed"); + if (!TAILQ_EMPTY(&vp->v_dirtyblkhd) || !TAILQ_EMPTY(&vp->v_cleanblkhd)){ + /* + * NFS calls vinvalflush on *live* vnodes. This kind of + * failure is to be expected. Retry a few times and give + * up if we are not getting anywhere. It isn't really + * important in this case anyway as long as we flushed + * everything that existed before we were called. + */ + if (flags & V_NFSFLUSH) { + retrycount++; + if (retrycount <= 5) { + printf( + "vinvalbuf: lost flush race #%d on NFS live vnode; restarting\n", + retrycount); + goto restart; + } else { + printf( + "vinvalbuf: lost flush race #%d on NFS live vnode; giving up\n", + retrycount); + } + } else { + panic("vinvalbuf: flush failed"); + } + } return (0); } Index: nfs/nfs_vnops.c =========================================================================== --- nfs/nfs_vnops.c 2002/10/18 08:38:40 #5 +++ nfs/nfs_vnops.c 2002/10/18 08:38:40 @@ -492,16 +492,16 @@ return (error); if (np->n_lrev != np->n_brev || (np->n_flag & NQNFSNONCACHE)) { - if ((error = nfs_vinvalbuf(vp, V_SAVE, ap->a_cred, - ap->a_p, 1)) == EINTR) + if ((error = nfs_vinvalbuf(vp, V_SAVE | V_NFSFLUSH, + ap->a_cred, ap->a_p, 1)) == EINTR) return (error); np->n_brev = np->n_lrev; } } } else { if (np->n_flag & NMODIFIED) { - if ((error = nfs_vinvalbuf(vp, V_SAVE, ap->a_cred, - ap->a_p, 1)) == EINTR) + if ((error = nfs_vinvalbuf(vp, V_SAVE | V_NFSFLUSH, + ap->a_cred, ap->a_p, 1)) == EINTR) return (error); np->n_attrstamp = 0; if (vp->v_type == VDIR) @@ -517,7 +517,8 @@ if (np->n_mtime != vattr.va_mtime.tv_sec) { if (vp->v_type == VDIR) np->n_direofoffset = 0; - if ((error = nfs_vinvalbuf(vp, V_SAVE, + if ((error = nfs_vinvalbuf(vp, + V_SAVE | V_NFSFLUSH, ap->a_cred, ap->a_p, 1)) == EINTR) return (error); np->n_mtime = vattr.va_mtime.tv_sec; @@ -595,7 +596,7 @@ error = nfs_flush(vp, ap->a_cred, MNT_WAIT, ap->a_p, cm); /* np->n_flag &= ~NMODIFIED; */ } else { - error = nfs_vinvalbuf(vp, V_SAVE, ap->a_cred, ap->a_p, 1); + error = nfs_vinvalbuf(vp, V_SAVE | V_NFSFLUSH, ap->a_cred, ap->a_p, 1); } np->n_attrstamp = 0; } @@ -3450,7 +3451,7 @@ vm_object_page_clean(vp->v_object, 0, 0, OBJPC_INVAL|OBJPC_SYNC); } VOP_UNLOCK(vp, 0, p); - error = nfs_vinvalbuf(vp, V_SAVE, ap->a_cred, p, 1); + error = nfs_vinvalbuf(vp, V_SAVE | V_NFSFLUSH, ap->a_cred, p, 1); if (error) { return (error); } Index: sys/vnode.h =========================================================================== --- sys/vnode.h 2002/10/18 08:38:40 #15 +++ sys/vnode.h 2002/10/18 08:38:40 @@ -263,6 +263,7 @@ #define WRITECLOSE 0x0004 /* vflush: only close writable files */ #define DOCLOSE 0x0008 /* vclean: close active files */ #define V_SAVE 0x0001 /* vinvalbuf: sync file first */ +#define V_NFSFLUSH 0x0002 /* vinvalbuf: live vnode via nfs */ #define REVOKEALL 0x0001 /* vop_revoke: revoke all aliases */ #define VREF(vp) vref(vp) --k1lZvvs/B4yU6o8G-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Oct 19 0:39:16 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E08137B401 for ; Sat, 19 Oct 2002 00:39:11 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 083C343E9C for ; Sat, 19 Oct 2002 00:39:10 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA32031; Sat, 19 Oct 2002 17:39:02 +1000 Date: Sat, 19 Oct 2002 17:49:49 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: BOUWSMA Beery Cc: freebsd-fs@FreeBSD.ORG Subject: Re: UFS2 panic (and other issues) at mount with unusual `newfs' values In-Reply-To: <200210121522.g9CFMMt00455@MAIL.NetScum.DynDNS.dK> Message-ID: <20021019165432.W2104-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 12 Oct 2002, BOUWSMA Beery wrote: > [IPv6-only address above; strip the obvious for IPv4-only mail] > > About three months ago, I bothered both this list and -current with > a message, and I've finally gotten around to taking a closer look at > it, keeping it in -fs this time. I wrote: > > > It seems that any -f fsize value larger than 8192 given to `newfs' > > creates a UFS2 filesystem that causes a panic when mounted, even > > > #15 0xc0297772 in ffs_mount (mp=0xc1918400, path=0xc1922180 "/mnt", data=---Can' > > t read userspace from dump, or kernel process--- > > Adding some debuggery makes it appear that the real crash occurs > in sys/ufs/ffs/ffs_vfsops.c in ffs_mountfs() right here: > > /* XXX DEBUG */ printf("ffs_mountfs: checkpoint 9\n"); > bcopy(bp->b_data, ump->um_fs, (u_int)fs->fs_sbsize); > /* XXX DEBUG */ printf("ffs_mountfs: checkpoint 10\n"); > > This should be line 690, plus or minus a few, in 14.Sep 1.190 > revision of this (last one I tried to build). The panic is just because we have allocated a buffer of size SBLOCKSIZE using bread(), but here we bcopy an amount potentially larger than SBLOCKSIZE into the buffer. Your patch that was recently committed to newfs/mkfs.c stops mkfs creating filesystems with such a larger fs_sbsize. I use the following patches which would have turned the panic into a mount failure. The original version of these was to try to get MAXBSIZE = DEV_BSIZE working so that the block size could be the same as the fragment size even when the fragment size is DEV_BSIZE. This doesn't quite work due to problems with fs_sbsize being small instead of large. IIRC, sizeof(struct fs) is slightly less than 1536 and things fail unless fs_bsize is larger than this (it must be at least 2048 after rounding). %%% Index: ffs_vfsops.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v retrieving revision 1.194 diff -u -2 -r1.194 ffs_vfsops.c --- ffs_vfsops.c 15 Oct 2002 20:00:06 -0000 1.194 +++ ffs_vfsops.c 16 Oct 2002 12:47:01 -0000 @@ -429,8 +425,17 @@ newfs->fs_magic != FS_UFS2_MAGIC) || newfs->fs_bsize > MAXBSIZE || - newfs->fs_bsize < sizeof(struct fs)) { - brelse(bp); - return (EIO); /* XXX needs translation */ + newfs->fs_sbsize > SBLOCKSIZE) { + bp->b_flags |= B_INVAL | B_NOCACHE; + brelse(bp); + return (EIO); /* XXX needs translation */ } + if (newfs->fs_bsize < sizeof(struct fs)) + printf("newfs->fs_bsize < sizeof(struct fs) (%lu <= %lu)\n", + (u_long)newfs->fs_bsize, (u_long)sizeof(struct fs)); + if (newfs->fs_sbsize != fragroundup(newfs, sizeof(struct fs))) + printf( + "newfs->fs_sbsize != fragroundup(newfs, sizeof(struct fs)) (%lu != %lu)\n", + (u_long)newfs->fs_sbsize, + (u_long)fragroundup(newfs, sizeof(struct fs))); /* * Copy pointer fields back into superblock before copying in XXX @@ -625,6 +623,7 @@ fs->fs_sblockloc == sblockloc)) && fs->fs_bsize <= MAXBSIZE && - fs->fs_bsize >= sizeof(struct fs)) + fs->fs_sbsize <= SBLOCKSIZE) break; + bp->b_flags |= B_INVAL | B_NOCACHE; brelse(bp); bp = NULL; @@ -685,5 +690,5 @@ ump->um_vfree = ffs_vfree; bcopy(bp->b_data, ump->um_fs, (u_int)fs->fs_sbsize); - if (fs->fs_sbsize < SBLOCKSIZE) + if (fs->fs_sbsize != fs->fs_bsize) bp->b_flags |= B_INVAL | B_NOCACHE; brelse(bp); %%% Notes on the above patch: %%% % Index: ffs_vfsops.c % =================================================================== % RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v % retrieving revision 1.194 % diff -u -2 -r1.194 ffs_vfsops.c % --- ffs_vfsops.c 15 Oct 2002 20:00:06 -0000 1.194 % +++ ffs_vfsops.c 16 Oct 2002 12:47:01 -0000 % @@ -429,8 +425,17 @@ % newfs->fs_magic != FS_UFS2_MAGIC) || % newfs->fs_bsize > MAXBSIZE || % - newfs->fs_bsize < sizeof(struct fs)) { % - brelse(bp); % - return (EIO); /* XXX needs translation */ % + newfs->fs_sbsize > SBLOCKSIZE) { Don't reject filesystems with a small blocksize, since these can work. Reject filesystems with a too-large fs_sbsize instead. % + bp->b_flags |= B_INVAL | B_NOCACHE; Discard the buffer immediately since we are certain we don't want it, and keeping buffers of unusual sizes around can be dangerous. The usual size is fs_bsize for a valid filesystems, and here we don't even have a valid filesystem. % + brelse(bp); % + return (EIO); /* XXX needs translation */ Fix indentation. % } % + if (newfs->fs_bsize < sizeof(struct fs)) % + printf("newfs->fs_bsize < sizeof(struct fs) (%lu <= %lu)\n", % + (u_long)newfs->fs_bsize, (u_long)sizeof(struct fs)); % + if (newfs->fs_sbsize != fragroundup(newfs, sizeof(struct fs))) % + printf( % + "newfs->fs_sbsize != fragroundup(newfs, sizeof(struct fs)) (%lu != %lu)\n", % + (u_long)newfs->fs_sbsize, % + (u_long)fragroundup(newfs, sizeof(struct fs))); % /* % * Copy pointer fields back into superblock before copying in XXX Debugging code. newfs->fs_bsize can be smaller than sizeof(struct fs) when MAXBSIZE < 4096. Some of these cases worked for me and I think all should work provided the blocking is done carefully. % @@ -625,6 +623,7 @@ % fs->fs_sblockloc == sblockloc)) && % fs->fs_bsize <= MAXBSIZE && % - fs->fs_bsize >= sizeof(struct fs)) % + fs->fs_sbsize <= SBLOCKSIZE) % break; % + bp->b_flags |= B_INVAL | B_NOCACHE; % brelse(bp); % bp = NULL; As above (above is for the reload case; this is the main case). Invalidating the buffer is more useful here, since we bread() with size SBLOCKSIZE here but only want to keep a buffer of size fs_sbsize. % @@ -685,5 +690,5 @@ % ump->um_vfree = ffs_vfree; % bcopy(bp->b_data, ump->um_fs, (u_int)fs->fs_sbsize); % - if (fs->fs_sbsize < SBLOCKSIZE) % + if (fs->fs_sbsize != fs->fs_bsize) % bp->b_flags |= B_INVAL | B_NOCACHE; % brelse(bp); More superstition about keeping odd-size buffers. I think both of the conditions are wrong. Only buffers of size fs_sbsize are useful. %%% > First question: with UFS2, what should the values for sbsize > be, so I know if the above line is at fault, or if the numbers > I give below indicate a problem elsewhere, like in newfs or > something? I believe fs_sbsize is now just sizeof(struct fs) rounded up a little now that there is no rotational info at the end of it. It must be rounded to a multiple of DEV_BSIZE. Further rounding to a multiple of fs_bsize or SBLOCKSIZE isn't essential although it might simplify blocking. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message