Date: Wed, 27 Oct 2004 13:24:19 +0400 From: Pavel Merdine <freebsd-fs@merdin.com> To: Don Lewis <freebsd-fs@FreeBSD.org> Subject: Re[4]: panic again Message-ID: <766160464.20041027132419@merdin.com> In-Reply-To: <200410262025.i9QKPXeV018690@gw.catspoiler.org> References: <1357841854.20041026213409@merdin.com> <200410262025.i9QKPXeV018690@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello , Wednesday, October 27, 2004, 12:25:33 AM, you wrote: > On 26 Oct, Pavel Merdine wrote: >> Again, somehow after a panic on ONE file system, other filesystems are >> not fully synced. The system conplaints that they are dirty after >> restart. So it seems like one panic lead to corruption of another >> systems. Maybe I'm wrong here too. But I dont see any good in fsck-ing >> each time. > When the OS detects these types of problems, then something (we don't > know what) unexpected has happened, so we can no longer trust the state > of the machine. If we can't trust the state of the machine, then it is > dangerous to sync any of the file systems, because doing so could damage > them with corrupt data. I'm right then. Number of panic()s should be minimum. Because currently one error in one partition leads to corruption of other immediately (providing they do writes often). I think that is not acceptable. I just didn't make fsck, don't shoot me! >> Background fsck does not work in reality as well, because the system >> can panic thousand times before errors are fixed. > It might be a good idea to force a foreground fsck if the system panics > before a background fsck has marked a dirty filesystem clean. What I mean is there is no point having background fsck which can lead to corruption of all system partitions. Explanation: there is not guarantee that panic will not occur before fsck is done; that panic leads to reboot without other filesystems sync, so it'll lead the their corruption. -- / Pavel Merdine
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?766160464.20041027132419>