Date: Sat, 29 Aug 1998 01:52:50 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mike@smith.net.au (Mike Smith) Cc: julian@whistle.com, abial@nask.pl, freebsd-current@FreeBSD.ORG Subject: Re: It's MFS panic.. (Re: Panic with DEVFS) Message-ID: <199808290152.SAA00390@usr01.primenet.com> In-Reply-To: <199808271525.PAA00718@dingo.cdrom.com> from "Mike Smith" at Aug 27, 98 03:25:32 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > ooooohhhhhhh > > > > > > specfs is not active if DEVFS is active > > so the spec_fsync should not be called...... > > I bet it's hard coded into MFS.. > > It would seem to me that specfs shouldn't even be *built* if DEVFS is > enabled. Looking over Julian's shoulder, the MFS code explicitly makes calls through the specfs VOP table. Specifically, there is a vp that represents the mount point that is treated as a physical device. When you fsync (or getpages or putpages), you call it with a vp that results in you calling the specfs with a modified version of the vp (since the backing object is really anonymous pages). This results in a call into specfs on the mountpoint vp, that calls specfs again, which call mfs_strategy. All in all, it's a pretty lame implementation, since it means that the anonymous pages backing the object are not the same as the pages hung off the vnode of the fs mounted on the object. Sure, you may have to page pages in from real swap (the swap pager backs anonymous pages), but for pages that are in core and dirty, the "sync" should be a reference count decrement. This seems to be related to the remnants of the BSD non-overcommit memory, where dirty pages would have to be written to swap. Mind you, I prefer a slightly more complex implementation: I think it should be possible to shadow RAM to a special area (let's not call it a swap area, since then you would want to overcommit the RAM), in order to support a "suspend to disk". But the current MFS code is rather arcane for something that fronts a set of anonymous pages. I would recommend reimplementing this with a "Memory device" driver, and putting your standard FS on the thing, instead. At best, you would end up with unallocated pages (a "sparse" device), and at worst, the overhead can't be more than mfs->specfs->strategy->mfs->specfs->mfs. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808290152.SAA00390>