Date: Sat, 5 Jun 1999 03:24:07 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: Thu@apollo.backplane.com, 3@FreeBSD.ORG, Jun@FreeBSD.ORG, 1999@FreeBSD.ORG, 23.-0500@apollo.backplane.com (EST), nate@mt.sri.com (Nate Williams), freebsd-hackers@FreeBSD.ORG Subject: Re: Matt's Commit status (was Re: 3.2-stable, panic #12) Message-ID: <199906050824.DAA57904@dyson.iquest.net.> In-Reply-To: <199906040131.SAA01566@apollo.backplane.com> from Matthew Dillon at "Jun 3, 1999 06:31:36 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon said: > > I don't want to be a pest, because this really shouldn't be on an > open forum. But John: I would ask you questions and the answers I > would get would be in the form: "Nobody understands that > code but me, don't touch what you don't understand", or "The algorithm > is obvious from the code". This in regards to non-compartmentalized > algorithms strewn across half a dozen source files which are almost > universally lacking in comments of any substance. > The frustration that I was showing was a result of off the wall assertions being made, with few coherent questions. Your questions are often analogous to someone saying that the VM code sucks, but will you help me with it, by teaching it to me? Oh, by the way, I haven't read the docs that you asked me to... :-). Hows about the frustration of being asked to review code "corrections" (or even seeing commits) that show a confusion that would have been cleared up if the docs were read, and then time was spent to ask questions that are backed with some initial understanding? > > That VM code was very fragile. It mostly worked, but it was very fragile. > It still IS fragile. > Are you trying to assert that the code is broken, and you will come in on your white horse and fix it? The minor fixes that should really be done are little in comparisons with the complexities and work associated with the original innovation. Actually, there is alot in the (VM) code that causes it to be generally robust. It is important to make sure that the code is well understood, or the various mechanisms that do provide for robust behavior in various loading conditions will be broken. (Randomly changing code that the hacker doesn't understand will indeed make code appear to be fragile.) The VFS code does need work, but it should be done only if the reasons and effects of its design are well understood by the individuals doing the work. There is a lot of infomation available, and it is available for the asking. The interface to filesystems and how they work need to be done from scratch. The need for backwards compatibility is probably gone now, and has been less important after the softupdates being integrated. There are two significant approaches to fixing the interface, and my suggestion is to eliminate the block-buffer interface all together. That was on my list, and really would have taken only a few weeks of work (and alot of review and testing.) I suggest design consultation before design and implementation however. Note that there are alot of individuals with biased views as to how to do I/O, and some of them have really good ideas. The key is to integrate what is needed for the I/O subsystems, and what is needed for filesystems. The caching per-se is already handled architecturally, so almost any work on vfs_bio beyond minor fixes for NFS are probably wasted effort on a legacy design that is less efficient than need be. On of the original passes for the merged VM buffer cache eliminated the buffers except for metadata, and the scheme worked. Since the need for backwards compatibility is almost gone, totally eliminating the buffer cache (and associated metdata bp-buffers) would be a good project. By elimintaing VFS_BIO, 99% of the grunge code would be eliminated from the VM/VFS code. Most of the ugliness in the VM code is there in order to interoperate with filesystems, and the methods used for them. If the vfs_bio rework is done, and done properly, the issues of coherency with VM and across VFS layers will be very clean to implement. In essense, this would be a forward moving project, which would avoid massive amounts of rework, and minimize breaking existing code. I suspect that re-architecting vfs_bio would be the best possible time investment. Continual re-working of the code, when it is used in ways that it wasn't even architecturally designed for (e.g. NFS, LFS), is more of an exercise in continual polishing. Note that the architectural issues regarding vfs_bio and NFS appeared way before the FreeBSD code, but have been problematical from day one. Note all of the hackery in the NFS code to make the buffer cache paradigm sort-of work... LFS is yet another beast that has work arounds to support a buffer cache scheme. Someone who wants to do something creative, with a user population that would be very thankful and that person wants to work on VM or VFS code, will consider carefully the straightforward effort to redesign VFS_BIO. If you want, I can have a working copy for you in a couple of weeks!!! :-). -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. 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?199906050824.DAA57904>