From owner-freebsd-current Sun Sep 20 19:42:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA05504 for freebsd-current-outgoing; Sun, 20 Sep 1998 19:42:14 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from zone.syracuse.net (zone.syracuse.net [205.232.47.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA05489 for ; Sun, 20 Sep 1998 19:42:04 -0700 (PDT) (envelope-from green@zone.syracuse.net) Received: from localhost (green@localhost) by zone.syracuse.net (8.8.8/8.8.7) with ESMTP id WAA04718; Sun, 20 Sep 1998 22:37:43 -0400 (EDT) Date: Sun, 20 Sep 1998 22:37:43 -0400 (EDT) From: Brian Feldman To: Terry Lambert cc: Peter Wemm , jkh@time.cdrom.com, freebsd@timog.prestel.co.uk, current@FreeBSD.ORG Subject: Re: DEVFS & SLICE? In-Reply-To: <199809202151.OAA02593@usr04.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hmm... reference to MFS working? Really? I seem to notice otherwise. For instance: -CURRENT with 100% stability (pre [EPwhatever]-day) EXCEPT after a full 23 days of uptime (damn, it sure _was_ stable) my nice 100mb MFS /tmp, upon usage, died on me. Full halt, didn't get any core or anything. And it did it the previous week as well. I wasn't doing anything stressful anyway, the first crash I had with MFS was doing an opendir()/readdir() in ksh's globbing. After disabling MFS, the system can stay up pretty well, except for the now-apparent SoftUpdates problems.... anyway, to summarize: 1. MFS is unusable for long periods of time and a large area 2. ccd + softupdates + 2 vnode drives is not stable either (ahem, this one I don't expect to be stable, just letting anyone know in case they feel the urge to try it). Cheers, Brian Feldman On Sun, 20 Sep 1998, Terry Lambert wrote: > > I think Julian's Big Mistake (TM) was bundling the SLICE option with the > > nifty root and /dev bootstrap system. They don't really seem to be related > > and they seem to get easily mixed up.. Julian first described his design > > for 'slice' to me over 2 years ago, and I thought back then that it was > > ambitious and was going to be an uphill battle. > > See other posting. This problem occurs because the system insists > on making a distintion between root and non-root mounts ate the > FS level. This leads to a plethora of code duplication, and a > hell of a lot of potential problems. > > My complaint about the SLICE code is that it assumes an external agency > will do the disklabel/partition/extended-partition/etc. hacking on a > raw device (i.e., that there is a user space program, rather than an > ioctl(), that abstracts paritioning schemas). > > Given the f-ed-up nature of the VFS mount code, it's not surprising > that there should be trouble. > > I think SLICE did us a great service when it pointed out that the > MFS implementation was a kludge-on-a-kludge. The use of direct > calls to specfs in order to call back into the MFS strategy routine > for bmap/getpage/putpages shows that MFS is a gross hack, and needs > to be fixed. > > That the SLICE code was backed out instead of the MFS code fixed is > more of a tribute to the necessity of having a working (if half-assed) > MFS being important for the 3.0 release deadline, and people being > willing to do one kind of work (tree reversion) as opposed to another > (fixing MFS and/or writing a memory device driver that uses a kernel > process as a VM container context for the MFS data loaded off the boot > disk, and FFS-formating it, as a stopgap measure). > > This is, I think, a rather natural consequence of setting deadlines > in a volunteer organization, and so there's really nowhere to formally > lay the blame. > > But this has nothing to do with Julian's failing/merits as an architect > (even if I personally don't like aspects of the architecture he came > up with, for my own reasons -- i.e., I want device arrivals of non-sliced > devices to result in automatic mounts). > > > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message