Date: Wed, 21 Jul 2010 13:25:39 -0700 From: Kirk McKusick <mckusick@mckusick.com> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: "Mikhail T." <mi+thun@aldan.algebra.com>, fs@freebsd.org Subject: Re: panic: handle_written_inodeblock: bad size Message-ID: <201007212025.o6LKPdpD068355@chez.mckusick.com> In-Reply-To: <20100721091058.GA74971@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Wed, 21 Jul 2010 02:10:58 -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 > > On Tue, Jul 20, 2010 at 02:47:51PM -0700, Jeremy Chadwick wrote: > > On Tue, Jul 20, 2010 at 10:57:09AM -0700, Jeremy Chadwick wrote: > > > 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. > > > > > > [...] > > > 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. > > > > I've written (what I believe to be) the first stage of getting this > > accomplished, and have been (slowly) testing each of the functions I > > modified in src/sys/ufs/ffs/ffs_softdep.c. > > [...] > > The diff so far, I think, is around 20KBytes. > > I finished preliminary testing tonight. There were two functions which > I couldn't verify work because I couldn't get the kernel to call them no > matter what I tried: > > softdep_setup_allocext() > request_cleanup() The softdep_setup_allocext() function is only called when you set external attributes such as ACL parameters (try setfacl(1)). The request_cleanup() function is only called when your kernel is memory stressed from too many filesystem operations. You might get it to trigger by using sysctl to cut debug.max_softdeps to say 5000 then try removing a tree with at least 10000 files in it. > All the other functions I modified were tested by moving the panic() > call near the top of the function and doing whatever was needed. > Sometimes mounting a filesystem was all that was required to trigger it, > other times I had to make a new filesystem + sync, or umount. In one > case I had to make a UFS1+SU filesystem. It's not a completely 100% > accurate test, hence "preliminary". :-) Sounds good. > I also fixed a couple cosmetical items with the code (things not lining > up right, some strings having ":" at the end of them when it should have > been within the initial formatting string itself, and one function which > used %s for "softdep" instead of just using the actual string itself). > These were few and far between. > > Below is the patch/diff for RELENG_8 I've come up with. I only tested > this on amd64: > > http://jdc.parodius.com/freebsd/ffs_softdep.c.patch > > Kirk, if you could review this I'd appreciate it. I have grabbed your patch and will look it over in the next few days. > -- > | 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 | Thanks for taking the time to go though all those panics! Kirk McKusick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201007212025.o6LKPdpD068355>