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