Date: Tue, 20 Jul 2010 10:57:09 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Kirk McKusick <mckusick@mckusick.com> Cc: "Mikhail T." <mi+thun@aldan.algebra.com>, fs@freebsd.org Subject: Re: panic: handle_written_inodeblock: bad size Message-ID: <20100720175709.GA52321@icarus.home.lan> In-Reply-To: <201007201544.o6KFipaV084986@chez.mckusick.com> References: <20100720134931.GA41352@icarus.home.lan> <201007201544.o6KFipaV084986@chez.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100720175709.GA52321>