Date: Sat, 20 Feb 1999 22:28:15 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: tlambert@primenet.com, julian@whistle.com, andre.albsmeier@mchp.siemens.de, sanewo@ba2.so-net.ne.jp, freebsd-hackers@FreeBSD.ORG Subject: Re: softupdate panic, anyone seen this? Message-ID: <199902202228.PAA19198@usr08.primenet.com> In-Reply-To: <199902201015.CAA07195@apollo.backplane.com> from "Matthew Dillon" at Feb 20, 99 02:15:22 am
next in thread | previous in thread | raw e-mail | index | archive | help
> :> WHY would you async mount an MFS? > :> it's an MFS! > : > :So you don't have to stall the caller copying the page-off-vnode > :memory to the swappable-page memory. > > So you don't have to do a context switch for each individual strategy > call. That's what I meant by "stall". > I can now reliably make buildworld on the above said VN configuration > ( as /usr/obj ). It's sweet, too... softupdates does an incredible > job balancing the network load. It doles the file writes out to > the network so smoothly I at first didn't realize that it was working. Rightous. It's always the way that someone abuses a technology that makes the biggest steps forward. The unforseen application. It's terrifically funny that you get such a performance win from what is, in effect, "the anti-write-gatherer". 8-). At one time, write gathering was the be-all, end-all of NFS performance, short of battery backed static RAM. Think what you could do if you could use lease (opportunity lock) technology to manage distributed dependencies between two machines, using a Heidemann network proxy layer instead of relying on poor old NFS. There's actually a terrific paper out of Stanford on leases: Leases: an efficient fault-tolerant mechanism for distributed file cache consistency. Cary G. Gray and David R. Cheriton CS-TR-90-1298 January 1990 ...courtesy of http://sunsite.Berkeley.EDU/NCSTRL/ I'm pretty sure this is the basis of the NFSv3 LEASE code. I'm regretting ever more frequently the limitation of the soft updates technology to a specific soloution for a fixed directed acyclic graph (UFS + FFS order of operation dependencies), instead of a more general mechanism where edges are managed by contention resolvers (shades of netgraph). I know Kirk's stated reasons for this, but I have to say that I really, really disagree that specific registration of the UFS/FFS node contention resoloution code (e.g., a "dependency") would result in data structures any larger than the current ones. Besides, you only have to take the registration hit when you instance a file system, and filesystems know about themselves. Maybe someone who needs a PhD in CS will tackle generalizing the idea using the Ganger/Patt appendix A code so as to not "contaminate" themselves with the licensing issues for commercial use (e.g., too many cooks). I'd work on it, but I'm probably too polluted already, not from the code, but from the fact that Whistle has a strategic interest in having paid Kirk to do the port, and being an employee, I have a contract that prevents me from giving away the fort. 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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902202228.PAA19198>