Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Feb 2000 11:50:57 -0800
From:      Alfred Perlstein <alfred@FreeBSD.org>
To:        Luoqi Chen <luoqi@watermarkgroup.com>
Cc:        bde@zeta.org.au, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org
Subject:   Re: cvs commit: src/sbin/mount mount.8
Message-ID:  <20000222115057.A21720@fw.wintelcom.net>
In-Reply-To: <200002221548.KAA26366@lor.watermarkgroup.com>; from luoqi@watermarkgroup.com on Tue, Feb 22, 2000 at 10:48:59AM -0500
References:  <200002221548.KAA26366@lor.watermarkgroup.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Luoqi Chen <luoqi@watermarkgroup.com> [000222 08:18] wrote:
> > On Mon, 21 Feb 2000, Alfred Perlstein wrote:
> > 
> > > * Luoqi Chen <luoqi@watermarkgroup.com> [000221 20:33] wrote:
> > > > The danger of corruption when downgrading a rw mount to ro mount is real.
> > > > I had a correspondence with kirk regarding one possible of scenario quite
> > > > a while ago, but it was too nasty to fix (IIRC), so we dropped the issue.
> > > 
> > > Do you have this archived anywhere, or can you explain what goes wrong?
> > 
> > One problem (explained to me by Luoqi) is for unlinked open files.  Consider
> > the following sequence of events:
> > 
> >     (1) mount -o rw ...
> >     (2) fd = open("foo", O_WRONLY ...);
> >     (3) unlink("foo");
> >     (4) mount -u -o ro ... -> vflush(...);
> >     (5) close(fd); -> ufs_inactive(...);
> > 
> > Step (3) doesn't remove the inode because the file is open.  Step (5) can't
> > remove the inode because the filesystem is read-only.  Step (4) apparently
> > doesn't handle this problem (except possibly in the FORCECLOSE case).
> > 
> > I added a similar but relatively harmless bug in the special-file timestamp
> > optimisations.  Writing of timestamps is delayed until ufs_inactive(),
> > but that is too late if the filesystem has become read-only.
> > 
> > Bruce
> > 
> Thanks, Bruce, this refreshed my memory. I was having trouble digging
> through my emails. A small correction though, in step (2), open the
> file O_RDONLY. Because it is not open for writing, it would escape
> detection by vflush(WRITECLOSE) in step (4).
> 
> One fix is to modify vflush() to detect such cases, i.e.
>     (vp->v_writecount == 0 && ip->i_nlink == 0).
> But vflush() doesn't have access to the FS specific inode information,
> and we don't want to add any ufs specific code to vflush(), so the only
> option we have is to add a VOP callback to allow individual filesystem
> a chance to declare a vnode busy. (So it wasn't like what I said, too
> nasty to fix. Too lazy might be a more suitable word :-)
> 
> Even if we fixed this one, we are not sure if there isn't any other problem
> left that would compromise filesystem integrity (remember this part of the
> code is barely tested). I think a warning label is still warranted.

I agree, although the old one was a bit hysterical, is this truthful
and complete:

Downgrading a filesystem from read-write to read-only may cause
filesystem corruption and therefore should be avoided.
.Pp
It may take a few moments for a filesystem going from async to sync or 
noasync to become fully safe with regard to consistancy after the option
has been toggled.

?

thanks,
-Alfred


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




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