From owner-freebsd-current Sat Sep 19 02:31:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA15917 for freebsd-current-outgoing; Sat, 19 Sep 1998 02:31:35 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA15911 for ; Sat, 19 Sep 1998 02:31:33 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id CAA20970; Sat, 19 Sep 1998 02:31:00 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id CAA17340; Sat, 19 Sep 1998 02:30:59 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id CAA10502; Sat, 19 Sep 1998 02:30:58 -0700 (PDT) From: Don Lewis Message-Id: <199809190930.CAA10502@salsa.gv.tsc.tdk.com> Date: Sat, 19 Sep 1998 02:30:57 -0700 In-Reply-To: Terry Lambert "Re: panic: newdirrem inum 48733 should be 48732 (SMP+SOFTUPDATES)" (Sep 19, 8:10am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Terry Lambert , ken@plutotech.com (Kenneth D. Merry) Subject: Re: panic: newdirrem inum 48733 should be 48732 (SMP+SOFTUPDATES) Cc: andreas@klemm.gtn.com, current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sep 19, 8:10am, Terry Lambert wrote: } Subject: Re: panic: newdirrem inum 48733 should be 48732 (SMP+SOFTUPDATES) } > > People seem to be having problems with soft updates because of CAM. } > } > I doubt the problems are *because* of CAM. It's more likely that the } > problems are tickled/exacerbated/demonstrated by CAM. The pattern of I/O } > that CAM does is different than the old SCSI layer; CAM handles a far } > greater number of outstanding transactions. (as many as your combination } > of drives and controllers can handle) } } If people have applied L. Chen's patch, and are still having the } problem, I'd have to guess that what's happening is that CAM is } not honoring the order of requests in its commits to disk. I don't think this problem is CAM. In the case of the initiate_write_filepage panic, the softupdates code is doing some sanity checking on a buf before writing it to disk. In this case, some modifications have been made to the contents of the buf, but they can't be committed to disk because of other dependencies. For one reason or another the code decides it really needs to write this buf to disk, so it has to undo the modifications so that the disk contents will be in a consistent state. While the code is going through the list of the modifications and undoing them (with the buf locked), it notices that what is currently stored in the buf is not what it thinks was last put there, so it calls panic(). If the undo had succeeded, the buf would have been written to disk, then the changes would have been redone and the buf unlocked. } It is *imperitive* to the soft updates technology that async writes } occur in the order they are requested to occur; the main privision } of soft updates is to not advance the soft clock "wheel" until the } previous wheel slot writes have been committed, such that all } physical writes occur in dependency order. This is true, but it only makes a difference if there is a crash or the hardware gets suddenly turned off in the middle. If things are stored to disk in the wrong order and you don't get everything stored to disk, then the filesystem will be in an inconsistent state when the system boots, and you may be better off using newfs than fsck. If you could guarantee that the system would stay up until it went into a quiet state where you could flush everything to disk, it wouldn't matter what order things were written before that point. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message