NetBSD Problem Report #40470

From rmind@NetBSD.org  Sun Jan 25 01:28:41 2009
Return-Path: <rmind@NetBSD.org>
Received: by narn.NetBSD.org (Postfix, from userid 1391)
	id 6A85E63BFFA; Sun, 25 Jan 2009 01:28:41 +0000 (UTC)
Message-Id: <20090125012841.6A85E63BFFA@narn.NetBSD.org>
Date: Sun, 25 Jan 2009 01:28:41 +0000 (UTC)
From: rmind@netbsd.org
Reply-To: rmind@netbsd.org
To: gnats-bugs@NetBSD.org
Subject: WAPBL corrupts ext2fs
X-Send-Pr-Version: 3.95

>Number:         40470
>Category:       kern
>Synopsis:       WAPBL corrupts ext2fs
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    ad
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jan 25 01:30:00 +0000 2009
>Closed-Date:    Sun Feb 22 20:12:59 +0000 2009
>Last-Modified:  Tue Feb 24 04:15:06 +0000 2009
>Originator:     Mindaugas Rasiukevicius
>Release:        NetBSD 5.99.7
>Organization:
The NetBSD Project
>Environment:
>Description:
Kernel compiled with WAPBL option corrupts ext2 file systems.
Maybe some incorrectly handled hook in UFS layer?
>How-To-Repeat:
Perform some work on ext2 file system, eg. compile.
Check the file-system consistency (or even file contents).
>Fix:
Workaround: compile kernel without WAPBL option.

>Release-Note:

>Audit-Trail:
From: Greg Oster <oster@cs.usask.ca>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/40470: WAPBL corrupts ext2fs 
Date: Sat, 24 Jan 2009 20:06:51 -0600

 rmind@netbsd.org writes:
 > >Number:         40470
 > >Category:       kern
 > >Synopsis:       WAPBL corrupts ext2fs
 > >Confidential:   no
 > >Severity:       critical
 > >Priority:       high
 > >Responsible:    kern-bug-people
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Sun Jan 25 01:30:00 +0000 2009
 > >Originator:     Mindaugas Rasiukevicius
 > >Release:        NetBSD 5.99.7
 > >Organization:
 > The NetBSD Project
 > >Environment:
 > >Description:
 > Kernel compiled with WAPBL option corrupts ext2 file systems.
 > Maybe some incorrectly handled hook in UFS layer?
 > >How-To-Repeat:
 > Perform some work on ext2 file system, eg. compile.
 > Check the file-system consistency (or even file contents).
 > >Fix:
 > Workaround: compile kernel without WAPBL option.

 Was / mounted as a log filesystem?

 Later...

 Greg Oster


From: Mindaugas Rasiukevicius <rmind@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: Greg Oster <oster@cs.usask.ca>, kern-bug-people@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/40470: WAPBL corrupts ext2fs
Date: Sun, 25 Jan 2009 03:25:02 +0000

 Greg Oster <oster@cs.usask.ca> wrote:
 >  > >Description:
 >  > Kernel compiled with WAPBL option corrupts ext2 file systems.
 >  > Maybe some incorrectly handled hook in UFS layer?
 >  > >How-To-Repeat:
 >  > Perform some work on ext2 file system, eg. compile.
 >  > Check the file-system consistency (or even file contents).
 >  > >Fix:
 >  > Workaround: compile kernel without WAPBL option.
 >  
 >  Was / mounted as a log filesystem?
 >  

 Yes. It seems that without "log" for / it is fine (have not done extensive
 testing, though). Do you know the problem?

 >  Later...
 >  
 >  Greg Oster

 -- 
 Best regards,
 Mindaugas

From: David Holland <dholland-bugs@netbsd.org>
To: Mindaugas Rasiukevicius <rmind@netbsd.org>
Cc: Greg Oster <oster@cs.usask.ca>, kern-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
	gnats-bugs@netbsd.org
Subject: Re: kern/40470: WAPBL corrupts ext2fs
Date: Sun, 25 Jan 2009 07:10:13 +0000

 On Sun, Jan 25, 2009 at 03:48:22AM +0000, Mindaugas Rasiukevicius wrote:
  > > No, but I bet it's the same problem as in 40361.  (with wapbl on /, 
  > > it thinks it needs to call the wapbl bits for the ext2 filesystem when 
  > > doing a sync.... and it gets it Very Wrong.. )  My guess is that if 
  > > you had a DIAGNOSTIC kernel you'd see roughly the same trace as in 
  > > 40361.
  > 
  > Kernel with debugging options does not trigger that assert. Only PR/39914,
  > which I do not think is related.

 That doesn't mean it's not the same problem - the ultimate problem
 there is using the wrong fs's vnops and/or vfsops.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Andrew Doran <ad@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/40470: WAPBL corrupts ext2fs
Date: Sun, 25 Jan 2009 21:46:18 +0000

 This may be the ffs_full_fsync issue.

 Andrew

From: Andrew Doran <ad@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/40470 CVS commit: src/sys/ufs/ffs
Date: Sun,  1 Feb 2009 17:36:43 +0000 (UTC)

 Module Name:	src
 Committed By:	ad
 Date:		Sun Feb  1 17:36:43 UTC 2009

 Modified Files:
 	src/sys/ufs/ffs: ffs_vnops.c

 Log Message:
 PR kern/40469 5.0_BETA/amd64 INSTALL kernel panics when installing on log-enabled filesystems
 PR kern/40470 WAPBL corrupts ext2fs

 Don't touch inodes at all unless VOP_FSYNC(). Might fix the ext2fs problem,
 I am not sure.


 To generate a diff of this commit:
 cvs rdiff -r1.108 -r1.109 src/sys/ufs/ffs/ffs_vnops.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Soren Jacobsen <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/40470 CVS commit: [netbsd-5] src/sys/ufs/ffs
Date: Mon,  2 Feb 2009 21:17:09 +0000 (UTC)

 Module Name:	src
 Committed By:	snj
 Date:		Mon Feb  2 21:17:08 UTC 2009

 Modified Files:
 	src/sys/ufs/ffs [netbsd-5]: ffs_vnops.c

 Log Message:
 Pull up following revision(s) (requested by ad in ticket #395):
 	sys/ufs/ffs/ffs_vnops.c: revision 1.109
 PR kern/40469 5.0_BETA/amd64 INSTALL kernel panics when installing on
 log-enabled filesystems
 PR kern/40470 WAPBL corrupts ext2fs
 Don't touch inodes at all unless VOP_FSYNC(). Might fix the ext2fs problem,
 I am not sure.


 To generate a diff of this commit:
 cvs rdiff -r1.104.4.4 -r1.104.4.5 src/sys/ufs/ffs/ffs_vnops.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 08 Feb 2009 06:32:18 +0000
State-Changed-Why:
Can you check if ad's commit fixed it?


Responsible-Changed-From-To: kern-bug-people->ad
Responsible-Changed-By: ad@NetBSD.org
Responsible-Changed-When: Sat, 21 Feb 2009 20:03:36 +0000
Responsible-Changed-Why:
have a fix


State-Changed-From-To: feedback->closed
State-Changed-By: ad@NetBSD.org
State-Changed-When: Sun, 22 Feb 2009 20:12:59 +0000
State-Changed-Why:
fixed


From: Andrew Doran <ad@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/40470 CVS commit: src/sys
Date: Sun, 22 Feb 2009 20:10:25 +0000 (UTC)

 Module Name:	src
 Committed By:	ad
 Date:		Sun Feb 22 20:10:25 UTC 2009

 Modified Files:
 	src/sys/kern: vfs_wapbl.c
 	src/sys/miscfs/syncfs: sync_subr.c sync_vnops.c
 	src/sys/ufs/ffs: ffs_alloc.c ffs_vfsops.c ffs_vnops.c

 Log Message:
 PR kern/39564 wapbl performance issues with disk cache flushing
 PR kern/40361 WAPBL locking panic in -current
 PR kern/40361 WAPBL locking panic in -current
 PR kern/40470 WAPBL corrupts ext2fs
 PR kern/40562 busy loop in ffs_sync when unmounting a file system
 PR kern/40525 panic: ffs_valloc: dup alloc

 - A fix for an issue that can lead to "ffs_valloc: dup" due to dirty cg
   buffers being invalidated. Problem discovered and patch by dholland@.

 - If the syncer fails to lazily sync a vnode due to lock contention,
   retry 1 second later instead of 30 seconds later.

 - Flush inode atime updates every ~10 seconds (this makes most sense with
   logging). Presently they didn't hit the disk for read-only files or
   devices until the file system was unmounted. It would be better to trickle
   the updates out but that would require more extensive changes.

 - Fix issues with file system corruption, busy looping and other nasty
   problems when logging and non-logging file systems are intermixed,
   with one being the root file system.

 - For logging, do not flush metadata on an inode-at-a-time basis if the sync
   has been requested by ioflush. Previously, we could try hundreds of log
   sync operations a second due to inode update activity, causing the syncer
   to fall behind and metadata updates to be serialized across the entire
   file system. Instead, burst out metadata and log flushes at a minimum
   interval of every 10 seconds on an active file system (happens more often
   if the log becomes full). Note this does not change the operation of
   fsync() etc.

 - With the flush issue fixed, re-enable concurrent metadata updates in
   vfs_wapbl.c.


 To generate a diff of this commit:
 cvs rdiff -r1.22 -r1.23 src/sys/kern/vfs_wapbl.c
 cvs rdiff -r1.35 -r1.36 src/sys/miscfs/syncfs/sync_subr.c
 cvs rdiff -r1.25 -r1.26 src/sys/miscfs/syncfs/sync_vnops.c
 cvs rdiff -r1.120 -r1.121 src/sys/ufs/ffs/ffs_alloc.c
 cvs rdiff -r1.241 -r1.242 src/sys/ufs/ffs/ffs_vfsops.c
 cvs rdiff -r1.109 -r1.110 src/sys/ufs/ffs/ffs_vnops.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Soren Jacobsen <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/40470 CVS commit: [netbsd-5] src/sys
Date: Tue, 24 Feb 2009 04:13:35 +0000 (UTC)

 Module Name:	src
 Committed By:	snj
 Date:		Tue Feb 24 04:13:35 UTC 2009

 Modified Files:
 	src/sys/kern [netbsd-5]: vfs_wapbl.c
 	src/sys/miscfs/syncfs [netbsd-5]: sync_subr.c sync_vnops.c
 	src/sys/ufs/ffs [netbsd-5]: ffs_alloc.c ffs_vfsops.c ffs_vnops.c

 Log Message:
 Pull up following revision(s) (requested by ad in ticket #490):
 	sys/kern/vfs_wapbl.c: revision 1.23
 	sys/miscfs/syncfs/sync_subr.c: revision 1.36
 	sys/miscfs/syncfs/sync_vnops.c: revision 1.26
 	sys/ufs/ffs/ffs_alloc.c: revision 1.121
 	sys/ufs/ffs/ffs_vfsops.c: revision 1.242
 	sys/ufs/ffs/ffs_vnops.c: revision 1.110
 PR kern/39564 wapbl performance issues with disk cache flushing
 PR kern/40361 WAPBL locking panic in -current
 PR kern/40361 WAPBL locking panic in -current
 PR kern/40470 WAPBL corrupts ext2fs
 PR kern/40562 busy loop in ffs_sync when unmounting a file system
 PR kern/40525 panic: ffs_valloc: dup alloc
 - A fix for an issue that can lead to "ffs_valloc: dup" due to dirty cg
   buffers being invalidated. Problem discovered and patch by dholland@.
 - If the syncer fails to lazily sync a vnode due to lock contention,
   retry 1 second later instead of 30 seconds later.
 - Flush inode atime updates every ~10 seconds (this makes most sense with
   logging). Presently they didn't hit the disk for read-only files or
   devices until the file system was unmounted. It would be better to trickle
   the updates out but that would require more extensive changes.
 - Fix issues with file system corruption, busy looping and other nasty
   problems when logging and non-logging file systems are intermixed,
   with one being the root file system.
 - For logging, do not flush metadata on an inode-at-a-time basis if the sync
   has been requested by ioflush. Previously, we could try hundreds of log
   sync operations a second due to inode update activity, causing the syncer
   to fall behind and metadata updates to be serialized across the entire
   file system. Instead, burst out metadata and log flushes at a minimum
   interval of every 10 seconds on an active file system (happens more often
   if the log becomes full). Note this does not change the operation of
   fsync() etc.
 - With the flush issue fixed, re-enable concurrent metadata updates in
   vfs_wapbl.c.


 To generate a diff of this commit:
 cvs rdiff -r1.3 -r1.3.8.1 src/sys/kern/vfs_wapbl.c
 cvs rdiff -r1.34 -r1.34.20.1 src/sys/miscfs/syncfs/sync_subr.c
 cvs rdiff -r1.25 -r1.25.10.1 src/sys/miscfs/syncfs/sync_vnops.c
 cvs rdiff -r1.113 -r1.113.4.1 src/sys/ufs/ffs/ffs_alloc.c
 cvs rdiff -r1.239 -r1.239.2.1 src/sys/ufs/ffs/ffs_vfsops.c
 cvs rdiff -r1.104.4.5 -r1.104.4.6 src/sys/ufs/ffs/ffs_vnops.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

Home	PR Database Search