Date: Thu, 11 Mar 1999 06:58:51 -0800 From: Cy Schubert <cschuber@uumail.gov.bc.ca> To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> Cc: dbushong@CSUA.Berkeley.EDU (David Bushong), Thierry.Herbelot@alcatel.fr (HERBELOT Thierry), freebsd-stable@FreeBSD.ORG Subject: Re: syncing filesystems... giving up Message-ID: <199903111459.GAA00543@passer.osg.gov.bc.ca> In-Reply-To: Your message of "Wed, 10 Mar 1999 11:10:14 PST." <199903101910.LAA01125@passer.osg.gov.bc.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903111459.GAA00543>