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>