From owner-freebsd-fs  Tue Feb 22 20:17:14 2000
Delivered-To: freebsd-fs@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP
	id CB66937B7C2; Tue, 22 Feb 2000 20:17:02 -0800 (PST)
	(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.9.3/8.9.3) id UAA02433;
	Tue, 22 Feb 2000 20:46:11 -0800 (PST)
Date: Tue, 22 Feb 2000 20:46:11 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Kirk McKusick <mckusick@flamingo.McKusick.COM>
Cc: Terry Lambert <tlambert@primenet.com>, fs@freebsd.org,
	jkh@freebsd.org
Subject: Re: changing mount options still can cause damage?
Message-ID: <20000222204610.I21720@fw.wintelcom.net>
References: <200002230230.TAA27823@usr07.primenet.com> <200002230232.SAA22016@flamingo.McKusick.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200002230232.SAA22016@flamingo.McKusick.COM>; from mckusick@flamingo.McKusick.COM on Tue, Feb 22, 2000 at 06:32:25PM -0800
Sender: owner-freebsd-fs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

* Kirk McKusick <mckusick@flamingo.McKusick.COM> [000222 19:14] wrote:
> A downgrade from read-write to read-only does a complete flush
> of the filesystem before setting the clean bit in the superblock.
> So, even if you have been running async before or even during
> the period that you do the downgrade to read-only, you will
> not trash the filesystem. I do not believe that you are lying
> to anybody by deleting the commentary about cycling between
> read-only and read-write. Appropriate warnings about async are
> called for, however the only warning necessary about cycling
> between sync and async is that the danger of async does not
> go away for several minutes after you have cycled to sync.
> 
> 	~Kirk

You're saying the exact opposite of what Bruce and Luoqi said,
they both say that updating the mount from async -> noasync/sync
is safe because of the flush_files call.

Looking at the code you seem right...

("ffs/ffs_vfsops.c" line 186 of 1283)

	if (mp->mnt_flag & MNT_UPDATE) {
		ump = VFSTOUFS(mp);
		fs = ump->um_fs;
		devvp = ump->um_devvp;
		err = 0;
		ronly = fs->fs_ronly;	/* MNT_RELOAD might change this */
		if (ronly == 0 && (mp->mnt_flag & MNT_RDONLY)) {
			flags = WRITECLOSE;
			if (mp->mnt_flag & MNT_FORCE)
				flags |= FORCECLOSE;
			if (mp->mnt_flag & MNT_SOFTDEP) {
				err = softdep_flushfiles(mp, flags, p);
			} else {
				err = ffs_flushfiles(mp, flags, p);
			}
			ronly = 1;
		}

It sure looks like it forces the structures to disk because
ffs_flushfiles calls VOP_FSYNC on the filesystem dev vp.  Which I
would assume fixes up link counts for inodes possibly opened, but
deleted before the the filesystem is set to read-only.

ufs_close calls ufs_itimes which avoids attempting to update the
inode access time if the fs is readonly, so does ufs_inactive.

However the async -> noasync/sync doesn't do the same (fsync the
device vp), shouldn't it, and if it did, wouldn't that fix the
problem?  It's not like doing a fsync on the whole filesystem
at that point would be a common occurance.

I think you're correct however I'm assuming you've seen the case
brought up by Bruce and Luoqi, specifically the unlink and downgrade
to read-only.

thanks,
-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message