Date: Sun, 20 Sep 1998 22:37:43 -0400 (EDT) From: Brian Feldman <green@zone.syracuse.net> To: Terry Lambert <tlambert@primenet.com> Cc: Peter Wemm <peter@netplex.com.au>, jkh@time.cdrom.com, freebsd@timog.prestel.co.uk, current@FreeBSD.ORG Subject: Re: DEVFS & SLICE? Message-ID: <Pine.BSF.4.04.9809202233010.4492-100000@zone.syracuse.net> In-Reply-To: <199809202151.OAA02593@usr04.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.04.9809202233010.4492-100000>