Date: Mon, 10 Feb 1997 07:45:34 -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: daily panics, ffs_valloc: dup alloc - Good news! Message-ID: <199702101245.HAA26005@lakes.water.net>
next in thread | raw e-mail | index | archive | help
> J Wunsch wrote: > > > > As Thomas David Rivers wrote: > > > > > As I said before; I would test our Joerg's supposition. I'm happy to > > > report it seems to be right on the money! (Good work!) > > > can you guys explain the problem in a couple of sinple sentences? > Sure; The code in newfs; when the number of tracks is set to 1; sets the fs_cgmask to 0xffffffff. Later in ffs_valloc.c:ffs_vget (and other places) that value is logically negated, and anded with another value in the physical block offset calculation. Since 0xffffffff negated is 0, and that anded with anything is 0; it has the effect of eliminating some of the computation. Thus, physical block offset offset calculation to read blocks of the file system actually are incorrect. The incorrect block can sometimes have other information; causing panic's; etc... My previous mail details the ffs: dup alloc panic problem, in that the inode is allocated. Then, a incorrect block is read from the disk; causing the panic. This appears to happen on rather full file systems (since the probability of reading a different/allocated inode block increases) and when dealing with inodes that are close to the inode-per-group boundary. - Dave Rivers -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702101245.HAA26005>