Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!avdms8.msfc.nasa.gov!europa.eng.gtefsd.com!howland.reston.ans.net!xlink.net!pilhuhn!flatlin!bad From: bad@flatlin.ka.sub.org (Christoph Badura) Subject: Re: FFS bug fix? Organization: Guru Systems/Funware Department Date: Mon, 13 Sep 1993 16:33:02 GMT Message-ID: <CDAwn3.C4w@flatlin.ka.sub.org> References: <matsCD5KH2.FF4@netcom.com> Lines: 86 In <matsCD5KH2.FF4@netcom.com> mats@netcom.com (Mats Wichmann) writes: >I've heard a story that in the process of doing the log filesystem work >at Berkeley (which I guess didn't get released - or did it? I've heard >differing stories on this too), a long-standing bug was discovered (and >fixed) in the Fast File System which prevented files from being laid >down as contiguously as they might have, or some such. Does anyone >have more detail on this - and where would one find details on the fix? Chris Torek posted the fix in the following article. Now if someone would post that fix to ucb-fixes and perhaps to comp.bugs.sys5... I'm getting tired of reposting it every couple of weeks. ~From comp.unix.wizards Mon Jan 4 02:09:41 1993 ~Path: flatlin!smurf.sub.org!ira.uka.de!yale.edu!spool.mu.edu!agate!dog.ee.lbl.gov!horse.ee.lbl.gov!torek ~From: torek@horse.ee.lbl.gov (Chris Torek) ~Newsgroups: comp.unix.wizards ~Subject: Re: file system layout ~Date: 1 Jan 1993 00:08:16 GMT ~Organization: Lawrence Berkeley Laboratory, Berkeley CA ~Lines: 55 ~Message-ID: <28188@dog.ee.lbl.gov> ~References: <1992Dec30.163131.17280@ll.mit.edu> <lk6u47INN47f@appserv.Eng.Sun.COM> ~NNTP-Posting-Host: 128.3.112.15 In article <1992Dec30.163131.17280@ll.mit.edu> singer@ll.mit.edu (Matthew R. Singer) writes: >>Since I am writing just one big file on a newly formatted disk, it >>should be contiguous (right?) [under SunOS]. In article <lk6u47INN47f@appserv.Eng.Sun.COM> lm@slovax.Eng.Sun.COM (Larry McVoy) writes: >Nope. Even though I wacked it to do contig allocation when it can, it >still switches cylinder groups every meg or so. I suppose you could >dick around with the tuning parameters to make one mondo cyl group. The `change groups' strategy exists to prevent the local clustering tactics from turning the file system into a series of unmanageable clumps. By forcing a seek every 1 MB or so, the file system tries to guarantee a high probability of a `well positioned' block being available whenever needed. Without this, large files would fill their primary cylinder group, and new files created in that group would get scattered hither and yon. Of course, if you are just going to write one single file on a disk, the file system policies work against you. Then again, if you are going to use the entire disk as a single file, you hardly need a file system at all.... Incidentally, Margo Seltzer found the following bug in the original BSD block allocator: [ffs_alloc.c: your line numbers will differ; in fact your code might even differ a bit, and/or be found in ufs_alloc.c. Presumably this is fixed in SunOS.] *************** *** 458,464 **** */ nextblk = bap[indx - 1] + fs->fs_frag; ! if (indx > fs->fs_maxcontig && ! bap[indx - fs->fs_maxcontig] + blkstofrags(fs, fs->fs_maxcontig) ! != nextblk) return (nextblk); if (fs->fs_rotdelay != 0) --- 464,469 ---- */ nextblk = bap[indx - 1] + fs->fs_frag; ! if (indx < fs->fs_maxcontig || bap[indx - fs->fs_maxcontig] + ! blkstofrags(fs, fs->fs_maxcontig) != nextblk) return (nextblk); if (fs->fs_rotdelay != 0) Kirk got the test backwards originally, so the tunefs -a parameter never mattered.... I no longer have VAXen, but I am curious as to whether this fix might improve performance on the old RA81 disks. I was never able to tune those at all; the performance was always miserable, never more than a few hundred K per second. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov -- Christoph Badura --- bad@flatlin.ka.sub.org --- +49 721 606137 Personally, I don't care whether someone is cool enough to quote Doug Gwyn--I only care whether Doug Gwyn is cool enough to quote. -- Larry Wall