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>