Date: Wed, 23 Feb 2000 02:30:44 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mckusick@flamingo.McKusick.COM (Kirk McKusick) Cc: bright@wintelcom.net (Alfred Perlstein), fs@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: changing mount options still can cause damage? Message-ID: <200002230230.TAA27823@usr07.primenet.com> In-Reply-To: <200002220116.RAA18831@flamingo.McKusick.COM> from "Kirk McKusick" at Feb 21, 2000 05:16:09 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> * Kirk McKusick <mckusick@flamingo.McKusick.COM> [000221 16:30] wrote: > > Switching between read-only and read-write should never cause filesystem > > corruption. Running async can certainly lead to corruption if the > > system crashes. There is an indeterminate period of time after the > > system has been switched from async to sync before it will be stable > > again, but that period will rarely be more than a minute or two. The > > act of switching between sync and async should not cause corruption. > > It is just the inherent risk of corruption while running async. > > > > Kirk McKusick > > Then I vote to remove it, there's no reason we should be slandering > ourselves in our own manpages, the async option already describes > the dangers pretty clearly. > > May I axe it? > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > As far as I am concerned, you can axe it. > > ~Kirk If you do, the information will no longer be correct. Kirk said that: There is an indeterminate period of time after the system has been switched from async to sync before it will be stable again, but that period will rarely be more than a minute or two. But he didn't say why. The problem is that the vnodes containing the buffer cache for the devices themselves contain dirty data which has not been written out. Even if the filesystem was sync'ed out (it is), this dirty data can be a problem, if you switched from read-write to read-only, particularly, if you then crash, with the clean bit set in the superblock, but dirty buffers applicable to the FS still hanging around. This is really part and parcel with the stacking layer backing object cache coherency problem, which comes from the cached data on the underlying FS being clean and the upper level stuff being dirty: an inversion of the backing device vnode problem. I think you should correct the man page, noting the actual cause of the problem, rather than nuking it and making people think that life is all rosy, and that there isn't a bugaboo waiting to bite them on the arse. We haven't lied to people about async being dangerous in the past, we shouldn't lie to them about switching from read/write to read-only being dangerous for other reasons, either. Ideally, we would force a sync to have completed before returning, and force all the buffers out. This incoherency, incidently, is the same reason you have to unmount, tune, and remount to enable soft updates. I think that we could perhaps resolve this by suggesting a workaround of an unmount of the read/write, followed by a mount of the read-only, at least until the underlying update code is changed to be upper level code that calls the unmount/mount primitives itself. The reason it is as it is appears to be to enable update mounts in cases where file or directory handles are currently open and thus need to (A) survive across the update and (B) not prevent the update because the filesystem is considered "busy". This could probably be fixed by making the unmount in the unmount/mount sequence take an argument of "with intent to remount", or even "and then remount" (making it call the mount for remounting itself). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200002230230.TAA27823>