From owner-freebsd-stable Thu Mar 11 7: 2:14 1999 Delivered-To: freebsd-stable@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id DDDBB14D0F for ; Thu, 11 Mar 1999 07:02:12 -0800 (PST) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.9.1/8.8.8) id HAA16794; Thu, 11 Mar 1999 07:01:52 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda16790; Thu Mar 11 07:01:31 1999 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id GAA00543; Thu, 11 Mar 1999 06:59:31 -0800 (PST) Message-Id: <199903111459.GAA00543@passer.osg.gov.bc.ca> Received: from localhost.osg.gov.bc.ca(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost.osg.gov.bc.ca, id smtpdZTt536; Thu Mar 11 06:58:51 1999 X-Mailer: exmh version 2.0.2 2/24/98 Reply-To: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.1-RELEASE X-Sender: cschuber To: Cy Schubert - ITSD Open Systems Group Cc: dbushong@CSUA.Berkeley.EDU (David Bushong), Thierry.Herbelot@alcatel.fr (HERBELOT Thierry), freebsd-stable@FreeBSD.ORG Subject: Re: syncing filesystems... giving up In-reply-to: Your message of "Wed, 10 Mar 1999 11:10:14 PST." <199903101910.LAA01125@passer.osg.gov.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Mar 1999 06:58:51 -0800 From: Cy Schubert Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Scratch my previous patch, it didn't work. The one below does fix the problem, including the panic caused by files being (very) actively written to MFS at the moment of shutdown. It has been tested on one of my machines at home and a machine here at work. Instead of using the P_SYSTEM flag to avoid swapping MFS it uses P_NOSWAP. --- src/sys/ufs/mfs/mfs_vfsops.c.orig Thu Dec 31 20:14:11 1998 +++ src/sys/ufs/mfs/mfs_vfsops.c Wed Mar 10 21:08:13 1999 @@ -399,7 +399,8 @@ * can we swap out this process - not unless you want a deadlock, * anyway. */ - curproc->p_flag |= P_SYSTEM; + /* curproc->p_flag |= P_SYSTEM; */ + curproc->p_flag |= P_NOSWAP; while (mfsp->mfs_active) { while (bp = bufq_first(&mfsp->buf_queue)) { Any comments? Suggestions? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Province of BC In message <199903101910.LAA01125@passer.osg.gov.bc.ca>, Cy Schubert writes: > It looks like my patch didn't make it to the list yet (probably > still stuck on /var/spool at home after terminating my PPP > connection). From what I can tell I get fewer occurrences of > "giving up" with the following patch applied. I've submitted to > bugs: kern/10528. > > This patch removes the P_SYSTEM status from MFS when it receives a > signal to umount and die. The 2.2.x MFS did not set this bit. > > --- src/sys/ufs/mfs/mfs_vfsops.c.orig Thu Dec 31 20:14:11 1998 > +++ src/sys/ufs/mfs/mfs_vfsops.c Wed Mar 10 11:04:21 1999 > @@ -420,11 +420,15 @@ > */ > if (gotsig) { > gotsig = 0; > - if (dounmount(mp, 0, p) != 0) > + if (dounmount(mp, 0, p) != 0) { > + curproc->p_flag |= P_SYSTEM; > CLRSIG(p, CURSIG(p)); /* try sleep again.. */ > + } > } > - else if (tsleep((caddr_t)vp, mfs_pri, "mfsidl", 0)) > + else if (tsleep((caddr_t)vp, mfs_pri, "mfsidl", 0)) { > gotsig++; /* try to unmount in next pass */ > + curproc->p_flag &= ~P_SYSTEM; > + } > } > return (0); > } > > > > Regards, Phone: (250)387-8437 > Cy Schubert Fax: (250)387-5766 > Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca > ITSD Cy.Schubert@gems8.gov.bc.ca > Province of BC > > In message <199903101837.KAA21282@soda.CSUA.Berkeley.EDU>, David > Bushong writes > : > > Ah HAH! Thanks! Now I know what I changed just before this started > > happening to me too (I have an AHA2940UW). I will try putting umount /tmp > > in /etc/rc.shutdown, but what's the reason for this problem? I have lots > > of memory and like my nice fast /tmp... > > > > --David Bushong > > > > > Hello, > > > > > > One problem was the use of MFS (I had it for /tmp and had the same prob > > > with sync) > > > > > > I don't remember if this was fixed or not. > > > > > > TfH > > > > > > > > > Cy Schubert - ITSD Open Systems Group wrote: > > > > > > > > I've managed to convert a couple of systems to 3.1R. Both systems have > > > > SCSI controllers, one with 2940UW2, one SCSI hard disk, a SCSI CDROM > > > > drive, and 4mm external tape drive the other with a 1542CF, two SCSI > > > > hard disks (+ 2 IDE hard disks), SCSI CDROM drive, and a 4mm internal > > > > tape drive. In both cases I've noticed that when shutting the systems > > > > down (halt or reboot) I get "syncing filesystems... giving up" more > > > > frequently (about 75% of reboots) than under 2.x.x (2.0.5 - 2.2.8). > > > > Has anyone else noticed this? I haven't used 3.1R on IDE only systems > > > > (I have two other systems with only IDE peripherals, however these > > > > haven't been upgraded yet). One of the systems (the one with the > > > > 2940UW2) had been running with CAM patches installed on 2.2.6 through > > > > 2.2.8 with no problems. > > > > > > > > Does anyone have any ideas? > > > > > > > > Regards, Phone: (250)387-8437 > > > > Cy Schubert Fax: (250)387-5766 > > > > Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca > > > > ITSD Cy.Schubert@gems8.gov.bc.ca > > > Province of BC > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > with "unsubscribe freebsd-stable" in the body of the message > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-stable" in the body of the message > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-stable" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message