Date: Thu, 02 Dec 2010 09:03:34 -0500 From: Michael Butler <imb@protected-networks.net> To: Kirk McKusick <mckusick@mckusick.com> Cc: Kostik Belousov <kostikbel@gmail.com>, current@freebsd.org Subject: Re: How a full fsck screwed up my SU+J filesystem Message-ID: <4CF7A736.9090102@protected-networks.net> In-Reply-To: <201012020030.oB20Ubno068176@chez.mckusick.com> References: <201012020030.oB20Ubno068176@chez.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------010008030904080908020305 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 12/01/10 19:30, Kirk McKusick wrote: [ .. snip .. ] > > Thanks all: Garrett for the report, Peter for the way to reproduce > the problem, and Kostik for a fix. I have copied Jeff so that he can > confirm that Kostik's fix is the appropriate thing to do. And I will > take a look at fsck to see if I can make it a bit more paranoid about > removing .sujournal. > > Kirk McKusick There's another case that SU+J fails and the patch has not yet been committed .. specifically, when configure tries to do a directory rename test .. as below .. I am uncertain but it seems that 'dump -L' exhibits a similar behaviour .. completely hung on me at 1am this morning :-( imb -------- Original Message -------- Subject: Re: softupdate with journal panic Date: Tue, 24 Aug 2010 00:12:57 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Peter Holm <pho@freebsd.org> CC: Michael Butler <imb@protected-networks.net>, Jeff Roberson <jroberson@jroberson.net>, current@freebsd.org On Sun, Aug 22, 2010 at 03:21:04PM +0200, Peter Holm wrote: > On Sat, Aug 21, 2010 at 01:49:45PM -0400, Michael Butler wrote: > > While updating sysutils/coreutils port on -current as of this morning > > (SVN r211550), I noted a panic during the directory rename config test. > > > > Your problem seems identical to this report: > > http://docs.freebsd.org/cgi/mid.cgi?AANLkTinPjiOV21kDLZYV5WScrhLMN7DY8E8jVHWPU5mC > I believe that dotdotremref in this case is legitimately NULL. With this assumption, the following patch would help. --------------010008030904080908020305 Content-Type: text/x-diff; name="ffs_softdep-dir.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ffs_softdep-dir.patch" *** src/sys/ufs/ffs/ffs_softdep.c~ Fri Aug 20 18:10:34 2010 --- src/sys/ufs/ffs/ffs_softdep.c Mon Aug 23 22:14:48 2010 *************** *** 6770,6776 **** mkdir->md_jaddref = NULL; if (mkdir->md_state & MKDIR_PARENT) { if (cancel_jaddref(jaddref, NULL, ! &dirrem->dm_jwork) == 0) { free_jremref(dotdotremref); dotdotremref = NULL; } --- 6770,6777 ---- mkdir->md_jaddref = NULL; if (mkdir->md_state & MKDIR_PARENT) { if (cancel_jaddref(jaddref, NULL, ! &dirrem->dm_jwork) == 0 && ! dotdotremref != NULL) { free_jremref(dotdotremref); dotdotremref = NULL; } --------------010008030904080908020305--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CF7A736.9090102>