Date: Sun, 09 Feb 1997 16:47:17 -0800 From: Julian Elischer <julian@whistle.com> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: FreeBSD hackers <freebsd-hackers@freebsd.org>, Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> Subject: Re: Copious information on panic: ffs_valloc: dup alloc - IDEAS??? Message-ID: <32FE7015.2F1CF0FB@whistle.com> References: <199702091818.NAA23739@lakes.water.net> <Mutt.19970209220222.j@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32FE7015.2F1CF0FB>