From owner-freebsd-current Sun Sep 13 17:03:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA25573 for freebsd-current-outgoing; Sun, 13 Sep 1998 17:03:15 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA25562 for ; Sun, 13 Sep 1998 17:03:12 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id RAA29115; Sun, 13 Sep 1998 17:02:58 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp03.primenet.com, id smtpd029092; Sun Sep 13 17:02:51 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id RAA24759; Sun, 13 Sep 1998 17:02:49 -0700 (MST) From: Terry Lambert Message-Id: <199809140002.RAA24759@usr04.primenet.com> Subject: Re: Help, DEVFS/MFS is broken... To: abial@nask.pl (Andrzej Bialecki) Date: Mon, 14 Sep 1998 00:02:49 +0000 (GMT) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: from "Andrzej Bialecki" at Sep 14, 98 00:00:17 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This is yet another call for help to all those who know the filesystems, > to help fix this bug before 3.0-R... This is a genuine bug which panics > system in 100% cases, and makes any system using DEVFS and MFS unusable. > Below is an excerpt from my earlier posting, including the stack trace. > > I tried several times to contact Julian Elischer, but it looks like he > disappeared in a black hole... > > PS. If it's any good, I can open a PR on this... It's julian@whistle.com, and I saw him Friday, so I don't think there is any gravitational anomoly invloved... 8-). The problem is known. MFS calls specfs directly, which is the wrong thing to do, since in theory, there will be no specfs in the near future. I know Julian was working on this a week and a half ago. The real problem is that the MFS doesn't operate against a "memory device". If it did, then the bmap/getpages/putpages entry points could access the backing memory directly; instead, what happens is that they call specfs to do "I/O", which calls the strategy routine, which calls MFS's strategy routine. I don't know whether he plans to make a "memory device" that allocates a set number of swappable pages in the kernel virtual address space (which would be my preference -- then you could just run FFS on the thing, instead, and then later somone could hack up some MFS-specific page management so that it didn't double the pages for clean pages that have been accessed), or if he's just planning on "doing whatever kludges it takes" to get the exiting MFS up and running. In any case, he's aware of the problem, and *has* been working on it. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message