NetBSD Problem Report #30525

From www@netbsd.org  Tue Jun 14 18:57:08 2005
Return-Path: <www@netbsd.org>
Received: by narn.netbsd.org (Postfix, from userid 31301)
	id 2330A63B116; Tue, 14 Jun 2005 18:57:08 +0000 (UTC)
Message-Id: <20050614185708.2330A63B116@narn.netbsd.org>
Date: Tue, 14 Jun 2005 18:57:08 +0000 (UTC)
From: pavel.cahyna@st.mff.cuni.cz
Reply-To: pavel.cahyna@st.mff.cuni.cz
To: gnats-bugs@netbsd.org
Subject: remounting ffs read-only (mount -ur) does not sync metadata
X-Send-Pr-Version: www-1.0

>Number:         30525
>Category:       kern
>Synopsis:       remounting ffs read-only (mount -ur) does not sync metadata
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jun 14 18:58:00 +0000 2005
>Closed-Date:    
>Last-Modified:  Sun Dec 12 09:10:03 +0000 2010
>Originator:     Pavel Cahyna
>Release:        NetBSD 2.0_BETA i386
>Organization:
>Environment:
System: NetBSD 2.0_BETA (GENERIC_DIAGNOSTIC s patchem D. Reeda - PR#26839) #4: Wed Oct  6 10:13:10 CEST 2004
	pavel@pc:/mnt/obj/kompilace/jadra/compile/GENERIC_DIAGNOSTIC

>Description:
I was testing some patch to ipfilter and expected a kernel panic. To avoid
damage to my filesystem (especially because I was using async mount at that
time) I remounted it read-only before the test. As expected, syslogd started
complaining that it can't write to /var/log/messages, otherwise everything
seemed to be fine. The test resulted in a panic and after rebooting, fsck
said  that the root filesystem is clean. Immediately after the kernel
paniced again with: "panic: blkfree: freeing free frag". I ran fsck -f /, it
found and repaired some errors and everything was fine.

So, mount -ur / left the filesystem in an inconsistent state, which
shouldn't happen. And it marked it as clean, so this inconsistency can be
hard to notice.

This has been discussed in December 2004 - see the thread "FFS update
doesn't sync metadata?" starting with an email from Jaromir Dolecek:
Message-ID: <20041205135743.10000492192@s102-n054.tele2.cz>
>How-To-Repeat:
mount a FFS filesystem -o async,rw , then remount it with -o ro,update and run fsck.
Or hard reboot the machine and run fsck after.
Other people report this problem with softdeps instead of async.

See also the message cited above.
>Fix:
unknown.

>Release-Note:

>Audit-Trail:
From: "Darrin B.Jewell" <dbj@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/30525: remounting ffs read-only (mount -ur) does not sync metadata
Date: 28 Jun 2005 15:22:07 -0400

 The following three recipies will reproduce this bug:

 Recipe 1, layer mount, courtesy dyoung@
   newfs /dev/rwd1a
   mount_ffs /dev/wd1a /mnt
   mkdir /mnt/foo
   mkdir /mnt/bar
   mount_null /mnt/foo /mnt/bar
   echo test > /mnt/bar/test1
   echo test > /mnt/bar/test2
   mount_ffs -o update,ro /dev/wd1a /mnt

 Recipe 2: reference to unlinked file, courtesy atatat@
   newfs /dev/rwd1a
   mount_ffs /dev/wd1a /mnt
   touch /mnt/file
   tail -f /mnt/file &
   rm /mnt/file
   mount_ffs -o update,ro /dev/wd1a /mnt

 Recipe 3: async mount, as per this pr.
   newfs /dev/rwd1a
   mount_ffs -o async /dev/wd1a /mnt
   echo test > /mnt/test
   mount_ffs -o update,ro /dev/wd1a /mnt

 Analysis:

 At the time of remount, only files open for writing are synced.
 Unfortunately, each of the above cases have different reasons why
 there may be unflushed outstanding changes on files which are no
 longer open for writing.

 In case 1, layer mounts delay vnode inactivation until the vnode is
 reclaimed, allowing flushes to remain unsynced.

 In case 2, the unreferenced file needs to be handled similarly
 to a file open for writing.

 In case 3, async mounts delay inode updates indefinitely.

 Putting a simple ffs_sync call in the remount has a couple
 of minor problems, which need to be handled:
   - the readonly flag is already set on the mount point by
     that time, so the update call will be ignored.
   - referenced but unlinked files need to be inactivated
     rather than simply flushed.
   - ffs_sync skips over vnodes if it cannot get the vnode lock
     on first try, it probably shouldn't when MNT_WAIT

 These issues should be managable, I'll work on a fix.

 Darrin

Responsible-Changed-From-To: kern-bug-people->dbj
Responsible-Changed-By: dbj@netbsd.org
Responsible-Changed-When: Tue, 28 Jun 2005 19:23:59 +0000
Responsible-Changed-Why:
i'll work on a fix


State-Changed-From-To: open->analyzed
State-Changed-By: dbj@netbsd.org
State-Changed-When: Tue, 28 Jun 2005 19:23:59 +0000
State-Changed-Why:
analysis sent in email to attach to this bug


From: "Darrin B.Jewell" <dbj@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: netbsd-bugs@netbsd.org
Subject: Re: kern/30525: remounting ffs read-only (mount -ur) does not sync metadata
Date: 28 Jun 2005 17:23:37 -0400

 "Darrin B.Jewell" <dbj@netbsd.org> writes:
 > The following three recipies will reproduce this bug:

 I also wanted to add this fourth recipe, which I created
 after code inspection and testing:

   newfs /dev/rwd1a
   mount_ffs /dev/wd1a /mnt
   touch /mnt/test
   tail -f /mnt/test &
   echo test >> /mnt/test
   mount_ffs -o update,ro /dev/wd1a /mnt

 This is important because just having the file open
 for read is enough to keep the file from being flushed.

 Darrin

Responsible-Changed-From-To: dbj->kern-bug-people
Responsible-Changed-By: dbj@NetBSD.org
Responsible-Changed-When: Sun, 10 Aug 2008 20:50:55 +0000
Responsible-Changed-Why:
I cannot commit to working on this in the near future and it's on
the wishlist for 5.0


From: Andrew Doran <ad@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/30525 CVS commit: src/sys/kern
Date: Wed, 24 Sep 2008 10:07:19 +0000 (UTC)

 Module Name:	src
 Committed By:	ad
 Date:		Wed Sep 24 10:07:19 UTC 2008

 Modified Files:
 	src/sys/kern: vfs_syscalls.c

 Log Message:
 PR kern/30525 remounting ffs read-only (mount -ur) does not sync metadata

 Prevent r/w to r/o downgrade until such time as someone has verified all
 the relevant file system code.


 To generate a diff of this commit:
 cvs rdiff -r1.372 -r1.373 src/sys/kern/vfs_syscalls.c

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

From: Andrew Doran <andrew@hairylemon.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/30525 (remounting ffs read-only (mount -ur) does not sync metadata)
Date: Wed, 24 Sep 2008 10:41:54 +0000

 PR kern/38281 (mount reload results in crashes) details another failure
 mode.

 Andrew

From: Geert Hendrickx <ghen@telenet.be>
To: gnats-bugs@NetBSD.org
Cc: ad@netbsd.org
Subject: Re: kern/30525: remounting ffs read-only (mount -ur) does not sync
 metadata
Date: Mon, 6 Dec 2010 11:44:47 +0100

 Does this bug impact filesystems mounted with option "sync"?  If not, could
 remounting read-only be allowed again for synchronous mounts?

 (this is what I use on my Soekris router with root filesystem on a CF disk.)


 	Geert

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/30525: remounting ffs read-only (mount -ur) does not sync
 metadata
Date: Sun, 12 Dec 2010 09:06:54 +0000

 On Mon, Dec 06, 2010 at 10:45:02AM +0000, Geert Hendrickx wrote:
  > Does this bug impact filesystems mounted with option "sync"?  If not, could
  > remounting read-only be allowed again for synchronous mounts?
  >
  > (this is what I use on my Soekris router with root filesystem on a CF disk.)

 That's a good question... but given that part of the problem is that
 some of the metadata doesn't get synced because it isn't kept in the
 buffer cache, I wouldn't really be inclined to trust it.

 -- 
 David A. Holland
 dholland@netbsd.org

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.