Date: Sat, 19 Sep 1998 02:30:57 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Terry Lambert <tlambert@primenet.com>, ken@plutotech.com (Kenneth D. Merry) Cc: andreas@klemm.gtn.com, current@FreeBSD.ORG Subject: Re: panic: newdirrem inum 48733 should be 48732 (SMP+SOFTUPDATES) Message-ID: <199809190930.CAA10502@salsa.gv.tsc.tdk.com> In-Reply-To: Terry Lambert <tlambert@primenet.com> "Re: panic: newdirrem inum 48733 should be 48732 (SMP%2BSOFTUPDATES)" (Sep 19, 8:10am)
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809190930.CAA10502>