Date: Sun, 25 Aug 1996 13:36:26 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dyson@FreeBSD.org Cc: sysseh@devetir.qld.gov.au, freebsd-fs@FreeBSD.org, current@FreeBSD.org Subject: Re: The VIVA file system (fwd) Message-ID: <199608252036.NAA21331@phaeton.artisoft.com> In-Reply-To: <199608250445.XAA05829@dyson.iquest.net> from "John S. Dyson" at Aug 24, 96 11:45:53 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Anybody have opinions on this vs LFS? Are we still waiting for the Lite-2 > > stuff, before LFS can go in? > > Looks interesting, but LFS is also. Some of the improvements will appear > when we get our implementation of properly delayed writes working for > UFS. I am sure that someone will take-on LFS when Lite-2 stuff goes > in, even I might (shiver :-)). The VIVA stuff is, I think, overoptimistic. They have made a number of claims in the University of Kentucky papers that were published about two years ago that seem to rely on overly optimistic assumptions about policy and usage. They also seemed to pick "worst case" scenarios for comparison with FFS, and avoided FFS best case. This is not nearly as bad as the MACH MSDOSFS papers, which intentioanlly handicapped FFS through parameter setting and cache reduction, while caching the entire DOS FAT in core was seen as being acceptable, to compare their work to FFS. But it is certainly not entirely unbiased reporting. Several of their approaches will (if you have read the Herrin/Finkel paper in any depth) apply directly to FFS with little or no modification. The file delete benchmarks are especially telling; they are comparing directory entry manipulation policy, which has little to do with the ability of the file system to store files at all. The dog-legs in the creation result from similar effects. The read and rewrite differences are moslty attributable to policy issues in the use of FFS "optimizations" which are inapropriate to the hardware used. You can see from the block-sized based divergence in the single file case that the dog-legs one would expect when the use of indirect blocks comes into play are missing. This refutes their claim of where the actual wins are coming from. I would be interested to see how VIVA performs in the following: 1) Unified VM/buffer cache implementation 2) Fixed write clustering; the BSD algorith traditionally has had problems which remain unaddressed (except in prototype code from Matt Day, which has not been externally distributed at all) 3) FFS optimizations for head positioning turned off, and/or use of FFS optimizationss on older drive hardware, where the optimizations are not actually pessimizations Finally, I am interested in, but suspicious of, their compression claims, since they also claim that the FFS performance degradation, which Knuth clearly shows to be a hash effect to be expected after an 85% fill (in "Sorting and Searching"), to be nonexistant. INRE: "where the wins come from", the "Discussion" reverses the claims made earlier in the paper -- we see that the avoidance of indirect blocks is not the primary win (a conclusion we came to on our own from viewing the earlier graphs). We also see in "Discussion" that caching file beginnings/ends in the inode itself is not a win as they has hoped. In fact, compilation times are pessimized by 25% by it. The final interesting aspect of VIVA is their crash recovery. The same effect can be had, with more general applicability, by examining the FS in terms of graph theory, and establishing node-relationship handlers for soft updates: an obvious extention of the Ganger/Patt work on soft updates, which disconnects the soft update mechanism from the FS implementation (the one obvious drawback of the Ganger/Patt work is that it is inhernetly tied to FFS, and each FS fro which it is to be impelemented requires it's own individual modifications and implementation of timer service routines). If you are looking for something to do a Master's Thesis on, moving applicable VIVA FS techniques into FFS would be one thing to consider, since it would allow you to determine the origin of the effects that are noted in the paper with better accuracy. If you are looking for a porting project, you could do worse. If you are trying to "keep up with Linux", it's probably not worth the direct effort, at least until, as another poster noted, there is sufficient grounds for a side-by-side comparison with a well studied FS implementation. My opinions, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608252036.NAA21331>