Date: Sat, 28 Aug 2004 12:43:10 +0400 From: Pavel Merdine <fbsdlist@merdin.com> To: freebsd-stable@freebsd.org Subject: Re[2]: ffs_alloc panic patch Message-ID: <146532856.20040828124310@kaluga.ru> In-Reply-To: <6.1.0.6.1.20040827124846.03ac02d0@popserver.sfu.ca> References: <1076237332.20040827215245@kaluga.ru> <20040827193605.GC28442@electra.cse.Buffalo.EDU> <6.1.0.6.1.20040827124846.03ac02d0@popserver.sfu.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello , Yes. That I was trying to say. For example, the Windows does not show the blue screen in such situations. In my practice I saw many times the situation of panic() when file system was not fsck'd. Actually it may even lead to security holes. E.g. a user may change an fs somehow to make it loop in panic forever... Friday, August 27, 2004, 11:55:39 PM, you wrote: > At 12:36 27/08/2004, Ken Smith wrote: >> ... Here you again wind up in a >> situation where the filesystem data structures on the disk can >> become corrupted. Typically at some point the ffs code will >> recognize that the metadata is incorrect and again a panic is >> better than trying to carry on pretending nothing is wrong. > Shouldn't a corrupt filesystem be handled by forcibly dismounting it, > rather than invoking panic()? We certainly don't want to keep on using > a corrupt filesystem, but we should attempt to isolate a single failing > piece of hardware rather than allowing it to bring down the entire > system. > Colin Percival -- / Pavel Merdine
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?146532856.20040828124310>