From root@CoolRat.org  Tue Feb 28 15:35:39 2006
Return-Path: <root@CoolRat.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 0203C16A420
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 28 Feb 2006 15:35:39 +0000 (GMT)
	(envelope-from root@CoolRat.org)
Received: from CoolRat.org (c-69-242-5-144.hsd1.pa.comcast.net [69.242.5.144])
	by mx1.FreeBSD.org (Postfix) with ESMTP id DBC1543D45
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 28 Feb 2006 15:35:37 +0000 (GMT)
	(envelope-from root@CoolRat.org)
Received: from localhost (localhost [127.0.0.1])
  (uid 0)
  by CoolRat.org with local; Tue, 28 Feb 2006 10:35:36 -0500
  id 003CBC1F.44046DC8.000006A2
Message-Id: <courier.44046DC8.000006A2@CoolRat.org>
Date: Tue, 28 Feb 2006 10:35:36 -0500
From: Yarema <yds@CoolRat.org>
Reply-To: Yarema <yds@CoolRat.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc: Doug White <dwhite@gumbysoft.com>,
  Dennis Koegel <amf@hobbit.neveragain.de>,
  "Marc G. Fournier" <scrappy@hub.org>, Martin Machacek <m@m3a.net>
Subject: panic: ufs_dirbad: bad dir
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         93942
>Category:       kern
>Synopsis:       [vfs] [patch] panic: ufs_dirbad: bad dir (patch from DragonFly)
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-fs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Feb 28 15:40:06 GMT 2006
>Closed-Date:    
>Last-Modified:  Fri Jun 20 20:03:31 UTC 2008
>Originator:     Yarema <yds@CoolRat.org>
>Release:        FreeBSD 6.1-PRERELEASE i386
>Organization:
>Environment:
System: FreeBSD 6.1-PRERELEASE #0: Mon Feb 27 04:52:11 EST 2006 i386

>Description:

This is at least the third file system which got hosed for me by the
ufs_dirbad bug on three different hard drives since 5.3 STABLE.
I suspect this is related to the following PRs:
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=49079
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=51001

In every case a process would lock up making the whole system
unresponsive.  A reboot, fsck -y in single user mode and another
reboot would produce the following during the mount of the corrupt
fs in rw mode:

bad dir ino 2 at  offset 16384: mangled entry
panic: ufs_dirbad: bad dir
cpuid = 0

Another reboot, fsck -y in single user mode and reboot produces the
same results repeatedly.  Previously I had recovered by mounting the
corrupt fs in ro mode, backup, newfs, restore.

Recently I noticed Matthew Dillon commit the following to the
DragonFly src repository:

http://leaf.DragonFlyBSD.org/mailarchive/commits/2006-02/msg00057.html

dillon      2006/02/21 10:46:56 PST

DragonFly src repository

  Modified files:
    sys/kern             vfs_cluster.c 
  Log:
  bioops.io_start() was being called in a situation where the buffer could
  be brelse()'d afterwords instead of I/O being initiated.  When this occurs,
  the buffer may contain softupdates-modified data which is never reverted,
  resulting in serious filesystem corruption.  When io_start is called on a
  buffer, I/O MUST be initiated and terminated with a biodone() or the buffer's
  data may not be properly reverted.
  
  Solve the problem by moving the io_start() call a little further on in the
  code, after the potential brelse().
  
  There is a possibility that this bug is responsible for the 'dirbad' panics
  often reported in DragonFly and FreeBSD circles.
  
  Revision  Changes    Path
  1.16      +7 -6      src/sys/kern/vfs_cluster.c

http://www.DragonFlyBSD.org/cvsweb/src/sys/kern/vfs_cluster.c.diff?r1=1.15&r2=1.16&f=u

Below is the equivalent patch to the FreeBSD RELENG_6 branch of
src/sys/kern/vfs_cluster.c

Hope this helps track down the problem.

>How-To-Repeat:
	mount <corrupt ufs>
>Fix:
--- src/sys/kern/vfs_cluster.c.orig	Fri Oct 28 03:28:27 2005
+++ src/sys/kern/vfs_cluster.c	Tue Feb 28 09:27:20 2006
@@ -881,11 +881,6 @@
 				bremfree(tbp);
 				tbp->b_flags &= ~B_DONE;
 			} /* end of code for non-first buffers only */
-			/* check for latent dependencies to be handled */
-			if ((LIST_FIRST(&tbp->b_dep)) != NULL) {
-				tbp->b_iocmd = BIO_WRITE;
-				buf_start(tbp);
-			}
 			/*
 			 * If the IO is via the VM then we do some
 			 * special VM hackery (yuck).  Since the buffer's
@@ -933,6 +928,11 @@
 			BUF_KERNPROC(tbp);
 			TAILQ_INSERT_TAIL(&bp->b_cluster.cluster_head,
 				tbp, b_cluster.cluster_entry);
+			/* check for latent dependencies to be handled */
+			if ((LIST_FIRST(&tbp->b_dep)) != NULL) {
+				tbp->b_iocmd = BIO_WRITE;
+				buf_start(tbp);
+			}
 		}
 	finishcluster:
 		pmap_qenter(trunc_page((vm_offset_t) bp->b_data),
>Release-Note:
>Audit-Trail:

From: Kris Kennaway <kris@obsecurity.org>
To: Yarema <yds@CoolRat.org>
Cc: FreeBSD-gnats-submit@FreeBSD.org,
	Dennis Koegel <amf@hobbit.neveragain.de>,
	Doug White <dwhite@gumbysoft.com>, Martin Machacek <m@m3a.net>
Subject: Re: kern/93942: panic: ufs_dirbad: bad dir
Date: Tue, 28 Feb 2006 14:53:43 -0500

 On Tue, Feb 28, 2006 at 10:35:36AM -0500, Yarema wrote:
 > Hope this helps track down the problem.
 
 Does it work for you? :)
 
 Kris

From: Yarema <yds@CoolRat.org>
To: FreeBSD-gnats-submit@FreeBSD.org, FreeBSD-current@FreeBSD.org
Cc: Kris Kennaway <kris@obsecurity.org>,
  Dennis Koegel <amf@hobbit.neveragain.de>,
  Doug White <dwhite@gumbysoft.com>, Martin Machacek <m@m3a.net>,
  David O'Brien <obrien@freebsd.org>, Scott Long <scottl@samsco.org>,
  Pawel Jakub Dawidek <pjd@FreeBSD.org>,
  David Rhodus <drhodus@machdep.com>
Subject: Re: kern/93942: panic: ufs_dirbad: bad dir
Date: Tue, 28 Feb 2006 18:43:58 -0500
 
 No way for me to know yet.  From what I gathered, mostly from this thread:
 <http://docs.FreeBSD.org/cgi/getmsg.cgi?fetch=331058+0+archive/2006/freebsd-current/20060108.freebsd-current>
 
 As per Matt Dillon 
 <http://docs.FreeBSD.org/cgi/getmsg.cgi?fetch=217892+0+/usr/local/www/db/text/2006/freebsd-current/20060226.freebsd-current>, 
 the corruption occurs much earlier than any consequences can be felt.
 The patch may prevent the corruption from occurring in the first place.
 But the patch does nothing for me now that I have a huge /home slice
 which cannot even be mounted as read-only in single user mode without
 triggering a page fault kernel panic in the mount process no matter
 how many times I run fsck -f on it.
 
 FWIW the page fault in the mount process is a different sort of kernel 
 panic than what is described in this kern/93942 PR above.  The page fault 
 occurs while attempting to mount read-only.  Attempting to mount raed-write 
 causes the panic: ufs_dirbad: bad dir
 
 One more note, hitting the power button when the machine is locked up 
 before the reboot and mount attempt which causes the panic produces the 
 following output every time the button is pressed:
 
 kernel: acpi: suspend request ignored (not ready yet)
 
 Seems like there's two separate problems:
 1) the root cause of the bad dir corruption.
 2) fsck -f doesn't fix it no matter how many times you run it.
 
 Any pointers on how to recover my /home slice will be greatly appreciated.
 
 -- 
 Yarema

From: "David Rhodus" <drhodus@machdep.com>
To: Yarema <yds@coolrat.org>
Cc: FreeBSD-gnats-submit@freebsd.org, FreeBSD-current@freebsd.org, 
	"Kris Kennaway" <kris@obsecurity.org>, 
	"Dennis Koegel" <amf@hobbit.neveragain.de>, 
	"Doug White" <dwhite@gumbysoft.com>, "Martin Machacek" <m@m3a.net>, 
	"David O'Brien" <obrien@freebsd.org>, 
	"Scott Long" <scottl@samsco.org>, 
	"Pawel Jakub Dawidek" <pjd@freebsd.org>
Subject: Re: kern/93942: panic: ufs_dirbad: bad dir
Date: Wed, 1 Mar 2006 15:10:38 -0500

 I have been working with the bad dir problem for several months and I
 have not had corruption which fsck would not correct.
 
 
 -DR

From: Kris Kennaway <kris@obsecurity.org>
To: David Rhodus <drhodus@machdep.com>
Cc: Yarema <yds@coolrat.org>, FreeBSD-gnats-submit@freebsd.org,
	FreeBSD-current@freebsd.org, Kris Kennaway <kris@obsecurity.org>,
	Dennis Koegel <amf@hobbit.neveragain.de>,
	Doug White <dwhite@gumbysoft.com>, Martin Machacek <m@m3a.net>,
	David O'Brien <obrien@freebsd.org>, Scott Long <scottl@samsco.org>,
	Pawel Jakub Dawidek <pjd@freebsd.org>
Subject: Re: kern/93942: panic: ufs_dirbad: bad dir
Date: Wed, 1 Mar 2006 15:19:37 -0500

 > I have been working with the bad dir problem for several months and I
 > have not had corruption which fsck would not correct.
 
 Me either, but that's surely small comfort to Yarema :-)
 
 Kris

From: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>
To: Kris Kennaway <kris@obsecurity.org>
Cc: David Rhodus <drhodus@machdep.com>,
        Dennis Koegel <amf@hobbit.neveragain.de>, FreeBSD-current@freebsd.org,
        Martin Machacek <m@m3a.net>, Pawel Jakub Dawidek <pjd@freebsd.org>,
        FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/93942: panic: ufs_dirbad: bad dir
Date: Thu, 2 Mar 2006 10:37:34 +0200 (EET)

 Hello!
 
 On Wed, 1 Mar 2006, Kris Kennaway wrote:
 >> I have been working with the bad dir problem for several months and I
 >> have not had corruption which fsck would not correct.
 >
 > Me either, but that's surely small comfort to Yarema :-)
 
   I think it would be great if originator of this PR tried to mount damaged fs
 ro, found broken directory (I think ino 2 is always the root directory,
 isn't it?), dumped and analyzed it's contents in order to find out how the
 corruption looks like. Then we could at least recreate the result of
 the corruption on test filesystem (by binary editing the media) and
 teach fsck how to cure such corruptions.
 
 Sincerely, Dmitry
 -- 
 Atlantis ISP, System Administrator
 e-mail:  dmitry@atlantis.dp.ua
 nic-hdl: LYNX-RIPE

From: Yarema <yds@CoolRat.org>
To: FreeBSD-gnats-submit@freebsd.org, FreeBSD-current@freebsd.org
Cc: Kris Kennaway <kris@obsecurity.org>,
  David Rhodus <drhodus@machdep.com>,
  Dennis Koegel <amf@hobbit.neveragain.de>,
  Doug White <dwhite@gumbysoft.com>, Martin Machacek <m@m3a.net>,
  David O'Brien <obrien@freebsd.org>, Scott Long <scottl@samsco.org>,
  Pawel Jakub Dawidek <pjd@freebsd.org>,
  Matthew Dillon <dillon@apollo.backplane.com>,
  Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>
Subject: Re: kern/93942: panic: ufs_dirbad: bad dir
Date: Thu, 02 Mar 2006 22:04:32 -0500

 Update:
 
 Attempting to mount my corrupt /home slice produces the following:
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 0; apic id = 00
 fault virtual address	= 0xdab2d004
 fault code		= supervisor read, page not present
 instruction pointer	= 0x20:0xc06ff7d7
 stack pointer		= 0x28:0xe9c56514
 frame pointer		= 0x28:0xe9c56570
 code segment		= base 0x0, limit 0xfffff, type 0x1b
 			= DPL 0, pres 1, def32 1, gran 1
 processor eflags	= interrupt enabled, resume, IOPL = 0
 current process		= 73 (mount)
 trap number		= 12
 panic: page fault
 cpuid = 0
 Uptime 23s
 Dumping 1023 MB (2 chunks)
   chunk 0: 1MB (159 pages) ... ok
   chunk 1: 1023MB (261748 pages) ... ok
 
 However I am able to mount this same corrupt /home partition with the 
 6.1-BETA2 kernel without error.  After tweaking, building and testing my 
 custom  KERNCONF the problem seems to be with:
 
 options	UFS_EXTATTR
 options	UFS_EXTATTR_AUTOSTART
 
 which according to the src/sys/ufs/ufs/README.* should only effect UFS1.  I 
 only use UFS2, so technically I do not need these options.
 
 To sum up: my computer became unresponsive.  Reboot and fsck produced a 
 "panic: ufs_dirbad: bad dir".  Many fsck -f runs later 'mount -r /home' 
 started causing the "Fatal trap 12: page fault while in kernel mode" panic. 
 Booting a kernel without options UFS_EXTATTR & UFS_EXTATTR_AUTOSTART does 
 not cause this mount proc kernel panic.  I have a vmcore dump if anyone 
 cares to look at it.
 
 Question: Why does fsck mark a UFS2 clean, but a kernel with options 
 UFS_EXTATTR & UFS_EXTATTR_AUTOSTART still cause a kernel panic on that one 
 UFS2 but none of the other UFS2 slices?
 
 Regarding the src/sys/kern/vfs_cluster.c patch.  All of the testing 
 described above was performed with the patch applied.  But the initial 
 corruption occurred before the patch.  It would be nice if someone who 
 understands that code looked at it, blessed it and got it committed.  We 
 will only find out if the patch indeed fixes the ufs_dirbad problem if all 
 those who've been bitten by this bug no longer run into this sort of 
 corruption over time.
 
 -- 
 Yarema

From: Robert Watson <rwatson@FreeBSD.org>
To: Yarema <yds@CoolRat.org>
Cc: FreeBSD-gnats-submit@freebsd.org, FreeBSD-current@freebsd.org,
	David Rhodus <drhodus@machdep.com>,
	Dennis Koegel <amf@hobbit.neveragain.de>,
	Martin Machacek <m@m3a.net>, Kris Kennaway <kris@obsecurity.org>,
	Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>,
	Pawel Jakub Dawidek <pjd@freebsd.org>
Subject: Re: kern/93942: panic: ufs_dirbad: bad dir
Date: Fri, 3 Mar 2006 03:51:45 +0000 (GMT)

 On Thu, 2 Mar 2006, Yarema wrote:
 
 > options	UFS_EXTATTR
 > options	UFS_EXTATTR_AUTOSTART
 
 If you disable just UFS_EXTATTR_AUTOSTART, does the panic go away?  The 
 autostart routine relies on reading directory data (or at least, performing 
 lookups) during the mount process.  While it shouldn't be running on UFS2, it 
 could be that it is, and if something has changed in the mount process so that 
 reading directories that early is no longer functional, it could be that this 
 causes an incorrect reporting of on-disk corruption (i.e., it could be a data 
 structure initialization problem or the like).
 
 Robert N M Watson

From: Yarema <yds@CoolRat.org>
To: Robert Watson <rwatson@FreeBSD.org>
Cc: FreeBSD-gnats-submit@freebsd.org, FreeBSD-current@freebsd.org,
  David Rhodus <drhodus@machdep.com>,
  Dennis Koegel <amf@hobbit.neveragain.de>,
  Martin Machacek <m@m3a.net>, Kris Kennaway <kris@obsecurity.org>,
  Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>,
  Pawel Jakub Dawidek <pjd@freebsd.org>
Subject: Re: kern/93942: panic: ufs_dirbad: bad dir
Date: Thu, 02 Mar 2006 23:39:45 -0500

 --On March 3, 2006 3:51:45 AM +0000 Robert Watson <rwatson@FreeBSD.org> 
 wrote:
 
 >
 > On Thu, 2 Mar 2006, Yarema wrote:
 >
 >> options	UFS_EXTATTR
 >> options	UFS_EXTATTR_AUTOSTART
 >
 > If you disable just UFS_EXTATTR_AUTOSTART, does the panic go away?  The
 > autostart routine relies on reading directory data (or at least,
 > performing lookups) during the mount process.  While it shouldn't be
 > running on UFS2, it could be that it is, and if something has changed in
 > the mount process so that reading directories that early is no longer
 > functional, it could be that this causes an incorrect reporting of
 > on-disk corruption (i.e., it could be a data structure initialization
 > problem or the like).
 >
 > Robert N M Watson
 
 Damn, I just reformatted the corrupt partition so I can no longer try this. 
 But as per Dmitry's suggestion before newfs wiped it all I did a:
 
 mount -r /home
 cat /home > /tmp/ar0s1e.ino2
 umount /home
 mount -r /dev/twed0s1e /home
 cat /home > /tmp/twed0s1e.ino2
 umount /home
 
 Where ar0s1e is the corrupt slice and the dir is 17408 bytes in size and 
 there seems to be a huge chunk of mostly null data following the entry for 
 lost+found.  twed0s1e is where I backed up the /home fs and the dir in a 
 more reasonable 1024 bytes in size.  Both files can be found at 
 <http://yds.CoolRat.org/freebsd/> along with an archive of my KERNCONF 
 files containing a short README explaining how I manage my KERNCONFs.
 
 -- 
 Yarema

From: Joerg Pernfuss <elessar@bsdforen.de>
To: Yarema <yds@CoolRat.org>
Cc: Robert Watson <rwatson@FreeBSD.org>, David Rhodus <drhodus@machdep.com>,
 Pawel Jakub Dawidek <pjd@freebsd.org>, Dennis Koegel
 <amf@hobbit.neveragain.de>, FreeBSD-current@freebsd.org, Martin Machacek
 <m@m3a.net>, Kris Kennaway <kris@obsecurity.org>, Dmitry Pryanishnikov
 <dmitry@atlantis.dp.ua>, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/93942: panic: ufs_dirbad: bad dir
Date: Tue, 7 Mar 2006 10:51:22 +0100

 --Sig_gS.8TuWKZ2Iur4zlrgP6xxZ
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 
 On Thu, 02 Mar 2006 23:39:45 -0500
 Yarema <yds@CoolRat.org> wrote:
 
 > --On March 3, 2006 3:51:45 AM +0000 Robert Watson
 > <rwatson@FreeBSD.org> wrote:
 >=20
 > >
 > > On Thu, 2 Mar 2006, Yarema wrote:
 > >
 > >> options	UFS_EXTATTR
 > >> options	UFS_EXTATTR_AUTOSTART
 > >
 > > If you disable just UFS_EXTATTR_AUTOSTART, does the panic go away?
 > > The autostart routine relies on reading directory data (or at least,
 > > performing lookups) during the mount process.  While it shouldn't be
 > > running on UFS2, it could be that it is, and if something has
 > > changed in the mount process so that reading directories that early
 > > is no longer functional, it could be that this causes an incorrect
 > > reporting of on-disk corruption (i.e., it could be a data structure
 > > initialization problem or the like).
 > >
 > > Robert N M Watson
 >=20
 > Damn, I just reformatted the corrupt partition so I can no longer try
 > this.
 
 But I do, I kept my bad partition all the times, (it was just
 /usr/ports/distfiles - lucky me).
 
 With normal, stock RELENG_6 sources from yesterday:
 
 Kernel with UFS_EXTATTR and UFS_EXTATTR_AUTOSTART -> panic on mount
 Kernel with UFS_EXTATTR without UFS_EXTATTR_AUTOSTART -> works
 
 I recently upgraded my RAM, so I had too little swap to dump, but if
 a dump needs to be generated, I'll remove a few of them and we'll
 have one.
 
 	Joerg
 
 --=20
 | /"\   ASCII ribbon   |  GnuPG Key ID | e86d b753 3deb e749 6c3a |
 | \ / campaign against |    0xbbcaad24 | 5706 1f7d 6cfd bbca ad24 |
 |  X    HTML in email  |  Now featuring a brand new GPG-Key!      |
 | / \     and news     |  Please update your keyring.             |
 
 --Sig_gS.8TuWKZ2Iur4zlrgP6xxZ
 Content-Type: application/pgp-signature; name=signature.asc
 Content-Disposition: attachment; filename=signature.asc
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.2 (FreeBSD)
 
 iD8DBQFEDVejH31s/bvKrSQRApgUAJ4yj45gvcwr+knfqO9Tv19YOwFr1gCcC+pz
 W9RxR+iMjGkeFbwZDpJaK+4=
 =+BQm
 -----END PGP SIGNATURE-----
 
 --Sig_gS.8TuWKZ2Iur4zlrgP6xxZ--
 

From: Matthew Dillon <dillon@apollo.backplane.com>
To: freebsd-gnats-submit@freebsd.org, freebsd-current@freebsd.org
Cc:  
Subject: Re: kern/93942: panic: ufs_dirbad: bad dir
Date: Thu, 4 May 2006 12:33:28 -0700 (PDT)

     I've found three additional issues which might be related to ufs_dirbad
     panics.  Again, unfortunately, no smoking gun.
 
     First, if B_NOCACHE gets set on a B_DIRTY buffer, the buffer can be
     lost without the data being written under certain conditions due
     to brelse() mechanics.  B_NOCACHE is typically set by softupdates 
     related code but can be set by other things as well (in particular,
     if a buffer is resized, and certain write/read combinations).  One
     might think that calling bwrite() after setting B_NOCACHE would be
     safe, but that is not necessarily true.  If a buffer is redirtied
     (B_DIRTY set) during the write, something which softupdates does all
     the time, B_NOCACHE almost certainly has to be cleared.  Of the three
     issues I found, this is the most likely cause.
 
     Second, vnode_pager_setsize() is being called too late in 
     ufs/ufs/ufs_lookup.c (line 733 in FreeBSD-current).  It is
     being called after the buffer has been instantiated.  This could
     create problems with the VMIO backing store for the buffer created
     by the UFS_BALLOC call.
 
     Third, vnode_pager_setsize() is being called too late in
     ufs/ufs/ufs_vnops.c (line 1557 in FreeBSD-current).  It is 
     being called after the buffer has been instantiated by UFS_BALLOC()
     in ufs_mkdir(), which could create problems with the buffer's VMIO
     backing store.
 
     --
 
     The M.O. of this corruption, after examining over a dozen kernel cores,
     makes me now believe that the corruption is occuring when the kernel
     attempts to append a full block to a directory.  The bitmaps are all
     good... it is if as though the directory block never got written and
     the data we are seeing is data that existed in tha block before the
     directory allocated it.  But, likewise, the issue has occured with
     different disk drivers so I think we can rule out a disk driver failure.
     The issue also seems to occur most often with large, 'busy' buffers
     (lots of directory operations going on).  Since no similar corruption
     has ever been reported for heavily used files, this supports the idea
     that it is *not* the disk driver.
 
     I believe that the data is getting written to the filesystem buffer
     representing the new block, but the buffer or its backing store
     is somehow getting thrown away without being written, or getting thrown
     away and then reinstantiated without being read.   The areas I 
     indicate in the above list are areas where data can potentially get
     thrown away or lost prior to a write.
 
 					-Matt
 					Matthew Dillon 
 					<dillon@backplane.com>
 
 
 (Patch against DragonFly, will not apply to FreeBSD directly, included for
 reference only):
 
 Index: kern/vfs_bio.c
 ===================================================================
 RCS file: /cvs/src/sys/kern/vfs_bio.c,v
 retrieving revision 1.53.2.1
 diff -u -r1.53.2.1 vfs_bio.c
 --- kern/vfs_bio.c	18 Apr 2006 17:12:25 -0000	1.53.2.1
 +++ kern/vfs_bio.c	24 Apr 2006 19:22:04 -0000
 @@ -972,6 +972,13 @@
  bdirty(struct buf *bp)
  {
  	KASSERT(bp->b_qindex == BQUEUE_NONE, ("bdirty: buffer %p still on queue %d", bp, bp->b_qindex));
 +	if (bp->b_flags & B_NOCACHE) {
 +		printf("bdirty: clearing B_NOCACHE on buf %p\n", bp);
 +		bp->b_flags &= ~B_NOCACHE;
 +	}
 +	if (bp->b_flags & B_INVAL) {
 +		printf("bdirty: warning, dirtying invalid buffer %p\n", bp);
 +	}
  	bp->b_flags &= ~(B_READ|B_RELBUF);
  
  	if ((bp->b_flags & B_DELWRI) == 0) {
 @@ -1096,6 +1103,11 @@
  
  	crit_enter();
  
 +	if ((bp->b_flags & (B_NOCACHE|B_DIRTY)) == (B_NOCACHE|B_DIRTY)) {
 +		printf("warning: buf %p marked dirty & B_NOCACHE, clearing B_NOCACHE\n", bp);
 +		bp->b_flags &= ~B_NOCACHE;
 +	}
 +
  	if (bp->b_flags & B_LOCKED)
  		bp->b_flags &= ~B_ERROR;
  
 Index: vfs/ufs/ufs_lookup.c
 ===================================================================
 RCS file: /cvs/src/sys/vfs/ufs/ufs_lookup.c,v
 retrieving revision 1.18
 diff -u -r1.18 ufs_lookup.c
 --- vfs/ufs/ufs_lookup.c	14 Sep 2005 01:13:48 -0000	1.18
 +++ vfs/ufs/ufs_lookup.c	24 Apr 2006 19:22:23 -0000
 @@ -716,6 +716,7 @@
  		 */
  		if (dp->i_offset & (DIRBLKSIZ - 1))
  			panic("ufs_direnter: newblk");
 +		vnode_pager_setsize(dvp, dp->i_offset + DIRBLKSIZ);
  		flags = B_CLRBUF;
  		if (!DOINGSOFTDEP(dvp) && !DOINGASYNC(dvp))
  			flags |= B_SYNC;
 @@ -727,7 +728,6 @@
  		}
  		dp->i_size = dp->i_offset + DIRBLKSIZ;
  		dp->i_flag |= IN_CHANGE | IN_UPDATE;
 -		vnode_pager_setsize(dvp, (u_long)dp->i_size);
  		dirp->d_reclen = DIRBLKSIZ;
  		blkoff = dp->i_offset &
  		    (VFSTOUFS(dvp->v_mount)->um_mountp->mnt_stat.f_iosize - 1);
 Index: vfs/ufs/ufs_vnops.c
 ===================================================================
 RCS file: /cvs/src/sys/vfs/ufs/ufs_vnops.c,v
 retrieving revision 1.32
 diff -u -r1.32 ufs_vnops.c
 --- vfs/ufs/ufs_vnops.c	17 Sep 2005 07:43:12 -0000	1.32
 +++ vfs/ufs/ufs_vnops.c	24 Apr 2006 19:22:42 -0000
 @@ -1420,12 +1420,12 @@
  	dirtemplate = *dtp;
  	dirtemplate.dot_ino = ip->i_number;
  	dirtemplate.dotdot_ino = dp->i_number;
 +	vnode_pager_setsize(tvp, DIRBLKSIZ);
  	if ((error = VOP_BALLOC(tvp, (off_t)0, DIRBLKSIZ, cnp->cn_cred,
  	    B_CLRBUF, &bp)) != 0)
  		goto bad;
  	ip->i_size = DIRBLKSIZ;
  	ip->i_flag |= IN_CHANGE | IN_UPDATE;
 -	vnode_pager_setsize(tvp, (u_long)ip->i_size);
  	bcopy((caddr_t)&dirtemplate, (caddr_t)bp->b_data, sizeof dirtemplate);
  	if (DOINGSOFTDEP(tvp)) {
  		/*
Responsible-Changed-From-To: freebsd-bugs->freebsd-fs 
Responsible-Changed-By: gavin 
Responsible-Changed-When: Fri Jun 20 20:01:34 UTC 2008 
Responsible-Changed-Why:  
Over to freebsd-fs, where hopefully somebody can assess this PR 

http://www.freebsd.org/cgi/query-pr.cgi?pr=93942 
>Unformatted:
