Date: Mon, 10 Feb 1997 07:40:22 -0500 (EST) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!uriah.heep.sax.de!joerg_wunsch, ponds!whistle.com!julian Cc: ponds!freebsd.org!freebsd-hackers, ponds!lakes.water.net!rivers Subject: Re: Copious information on panic: ffs_valloc: dup alloc - IDEAS??? Message-ID: <199702101240.HAA25989@lakes.water.net>
next in thread | raw e-mail | index | archive | help
> Julian Elischer wrote: > > J Wunsch wrote: > > > > As Thomas David Rivers wrote: > > > > > You're saying the code in newfs.c that sets NTRACKS to 1 and > > > NSECTORS to 4096 would be changed. > > > > Yes, to e.g. 2 * 2048 instead. It's a mileage number only anyway, > > since Poul found out (experimentally) that it just works better than > > any (un)real number on today's zone-bit recorded and large cache > > disks. > > > > > If this is so, doesn't that mean that everyone is using a file system > > > that is questionable. Aren't inode reads/writes going to the wrong > > > places (albeit consistently?) > > > > I'm no filesystem expert at all, but this seems to be the case. The > > failure picture matches consistently with the reported MFS troubles > > (including mine), and it's probably also responsible for some other > > panic PRs you could find in the GNATS database. > > > > -- > > > Kirk suggested setting the number of heads to 1 to > turn off the "selelct a nearby head" code.. > > if you make it have 2 heads, this code will be enabled > again and we'll lose the effect.. > it pessimise the accesses by switching to a differnt head that it > thinks has a nearby free block.. in the case of 2 heads (as suggested) > this is actually likely to be "NOT NEARBY" and we will lose > > you could HEAR the difference when we went to 1 head.. > > Hmmm... well, that's certainly not the best news. But I would assert that the file system isn't working properly without this problem corrected. An alternative I was considering was to set the file system's fs_cgmask to 0 if the number of tracks is 1. (Instead of it's current, problematic 0xffffffff). But, it's just a guess from my point of view; I'm no filesystem expert. I'll try that out and report back. If that works, then we can return to having NTRACKS be 1. - Dave Rivers -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702101240.HAA25989>