Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 04 Mar 2000 11:34:00 -0800
From:      Kirk McKusick <mckusick@flamingo.McKusick.COM>
To:        Alfred Perlstein <bright@wintelcom.net>
Cc:        Terry Lambert <tlambert@primenet.com>, fs@freebsd.org, jkh@freebsd.org, Bruce Evans <bde@zeta.org.au>
Subject:   Re: changing mount options still can cause damage? 
Message-ID:  <200003041934.LAA16343@flamingo.McKusick.COM>
In-Reply-To: Your message of "Tue, 22 Feb 2000 20:46:11 PST." <20000222204610.I21720@fw.wintelcom.net> 

next in thread | previous in thread | raw e-mail | index | archive | help
OK, I have finally had a chance to investigate these issues at
greater length and have come to the following conclusions:

1) As suggested below, it would be useful to ffs_flushfiles
(or softdep_flushfiles as appropriate) when changing from
async -> noasync/sync so that upon return from the mount
command the user knows that the filesystem is safe.

2) In reviewing my bug logs for FFS I have found the `corruption'
case to which I believe the bug entry in the manual page was
alluding. It is possible to get lost inodes in a filesystem
that has been downgraded to read-only even if it never ran
in async mode. The senario causing trouble goes as follows:

	A) a process opens a file for reading.
	B) the file is unlinked
	C) the filesystem is downgraded to read-only
	D) the process referencing the now unlinked
	   file exits or closes the file.

In this case, the the inode cannot be freed as the filesystem
is now in read-only mode. Corruption of this sort is not
particularly threatening as the lost inodes will be cleaned
up the next time `fsck -p' is run, but the resulting loss
of space may be annoying if the filesystem is nearly full.
The alternative is to vgone files with link counts of zero
when doing a (forcible) downgrade just as we do with files
that are open for writing. This would result in the inode
being released and the process seeing a dead file (again
just as it would for a file open for writing). This seems
a slightly odd semantic for a file open for reading, so I
have not done it. Does anyone have any views on whether the
filesystem should be changed in this way on forcible
downgrades?

	Kirk

=-=-=-=-=-=-=-=

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?

* 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]

=-=-=-=-=-=-=-=-=

Date: Fri, 25 Feb 2000 00:57:42 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
To: Alfred Perlstein <bright@wintelcom.net>
cc: Kirk McKusick <mckusick@flamingo.McKusick.COM>,
        Terry Lambert <tlambert@primenet.com>, fs@FreeBSD.ORG, jkh@FreeBSD.ORG
Subject: Re: changing mount options still can cause damage?

On Tue, 22 Feb 2000, Alfred Perlstein wrote:

> * Kirk McKusick <mckusick@flamingo.McKusick.COM> [000222 19:14] wrote:
> > ... 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...

> 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.

Copying the code in sync() and changing MNT_NOWAIT to MNT_WAIT in it
should work, modulo locking problems.  This applies to both async ->
noasync and nosync -> sync.

Bruce



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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003041934.LAA16343>