Date: Sat, 5 Oct 2002 13:30:36 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: "Steven G. Kargl" <kargl@troutmask.apl.washington.edu> Cc: "Brian F. Feldman" <green@freebsd.org>, freebsd-current@freebsd.org, kirk@freebsd.org Subject: Re: panic from _mutex_assert in kern_lock.c Message-ID: <Pine.NEB.3.96L.1021005132846.64999n-100000@fledge.watson.org> In-Reply-To: <200210051723.g95HNxKv014164@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 5 Oct 2002, Steven G. Kargl wrote: > I came to the same conclusion after I sent the original email. > > What I don't understand is how I ended up in ffs_snapshot(), because I > don't have a snapshot of /var. I tried snapshots when Kirk first > introduced the feature, but I removed all of the snapshots a long time > ago. Is there a flag in the superblock that I need to clear? > > One other point, the machine was doing a background fsck on /var. Does > a background fsck go through ffs_snapshot()? Yes -- the background file system checker creates a snapshot of the file system in the un-checked state, then performs the check against the snapshot. It trickles the changes generated against the snapshot into the live file system. Because of the conservative nature of failures with soft updates, the only theoretical inconsistencies relate either to marked as non-free yet unreferenced resources, and referenece counts that are high. The snapshot allows fsck a consistent view of the file system "as it was" so that it doesn't get confused by the live file system. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1021005132846.64999n-100000>