From owner-freebsd-fs@FreeBSD.ORG Tue Jul 20 17:57:11 2010 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E4501065676 for ; Tue, 20 Jul 2010 17:57:11 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 74D928FC0C for ; Tue, 20 Jul 2010 17:57:11 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta01.emeryville.ca.mail.comcast.net with comcast id kESA1e0071u4NiLA1HxBVm; Tue, 20 Jul 2010 17:57:11 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta21.emeryville.ca.mail.comcast.net with comcast id kHx91e00D3LrwQ28hHxA7k; Tue, 20 Jul 2010 17:57:10 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id AADC09B425; Tue, 20 Jul 2010 10:57:09 -0700 (PDT) Date: Tue, 20 Jul 2010 10:57:09 -0700 From: Jeremy Chadwick To: Kirk McKusick Message-ID: <20100720175709.GA52321@icarus.home.lan> References: <20100720134931.GA41352@icarus.home.lan> <201007201544.o6KFipaV084986@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007201544.o6KFipaV084986@chez.mckusick.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Mikhail T." , fs@freebsd.org Subject: Re: panic: handle_written_inodeblock: bad size X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 17:57:11 -0000 On Tue, Jul 20, 2010 at 08:44:51AM -0700, Kirk McKusick wrote: > You are on the right track with getting the filesystem information. > Any place that one has an inode (say pointer ip), it is possible > to get the filesystem information using ip->i_fs->fs_fsmnt. The > mount point can also be found from the mount-point structure. Kirk, thanks for chiming in! The latter is the one I'm not familiar with. Are you referring to "struct mount"? If so -- yeah I took a look at that one too, but found it to be used predominantly in other functions and wasn't sure how to "work backwards" to getting what was needed. I also wasn't sure what the difference was between fs_fsmnt vs. f_mntfromname (and f_mnttoname too) in struct mount. > So, it is almost always possible to make your way to fs_fsmnt. > Since soft updates only runs on mounted filesystems, you will never > have a case where the fs_fsmnt has not been filled in for you. Oh, cool. I was taking the paranoid approach ("does this really point to something that's valid? What if..."). :-) > You are right that you do not want to add a global variable. > Instead the fs_fsmnt should just be gathered from where-ever it > is available. Adding it to all the panic's will be a lot of work, > but I agree would be useful. I will look into doing so when I > get a chance. I'd like to volunteer to help implement this if at all possible. I don't mind doing the dirty work and having you review it. There are some functions which are fairly obvious when it comes to getting mountpoint information, and I think a good starting point (for me anyway) would be to enhance those. Standardising the panic() output cosmetically (meaning where in the string the mountpoint gets printed) would also be worthwhile. I'm of the opinion that it should be printed first, e.g.: panic("%s: softdep_setup_inomapdep: dependency for new inode already exists" mountpoint); The biggest problem (for me) is testing. I have no idea how to trigger the error conditions in these functions. I assume it varies; maybe through fsdb(8) or interactively dropping to DDB and forcing the condition. I tend to do all of my work on this sort on a VM of FreeBSD (using VMware Workstation), but if testing on bare metal is required I have a testbed as well. Let me know if you could. Thanks! -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |