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> In-Reply-To: <200002230232.SAA22016@flamingo.McKusick.COM>; from mckusick@flamingo.McKusick.COM on Tue, Feb 22, 2000 at 06:32:25PM -0800 References: <200002230230.TAA27823@usr07.primenet.com> <200002230232.SAA22016@flamingo.McKusick.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
* 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000222204610.I21720>