Date: Tue, 3 Jul 2007 21:42:05 -0400 From: Gary Palmer <gpalmer@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org> Subject: Re: FFS writes to read-only mount Message-ID: <20070704014205.GA53564@in-addr.com> In-Reply-To: <20070704102358.W95084@delplex.bde.org> References: <45F776AE.8090702@nokia.com> <20070314161041.GI7847@garage.freebsd.pl> <45F8EE27.6070208@nokia.com> <20070315090031.GB80993@deviant.kiev.zoral.com.ua> <4689EFAA.4080009@nokia.com> <20070704102358.W95084@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 04, 2007 at 11:08:36AM +1000, Bruce Evans wrote: > On Tue, 3 Jul 2007, David Cecil wrote: > > >in March I mailed the list about errors I'm seeing that look something > >like this: > >g_vfs_done():mirror/gmroots1f[WRITE(offset=1349091328, length=16384)]error > >= 1 > >(Note that gmroots1f is not a complete mirror set, just one disk ,and was > >never part of a complete mirror set. Also, partition f is the root > >partition.) > > > >The problem comes about because the underlying geom object has had its > >access permissions changed so that g_io_check fails due to acw being 0 (as > >per my original message at the end of this email). This problem is most > >easily reproducible when during boot if the root filesystem is changed > >from rw to ro mount. Our code is now 6.1-based. > > At least -current seems to have the opposite problem -- that acw is not > changed to 0 on mount -o ro, as shown by: > > boot > use the system a bit > # fsck -p / # fails of course since / is rw > # mount -u -o ro / # fails with EBUSY > # # I don't want to try mount -f ... / > # kill -TERM 1 # shut down to single user mode to run fsck safely > # umount -A # old bug: this still doesn't remount / ro > # not so old bug: it now tries to unmount devfs; this > # fails of course > # mount -u -o ro / # finish unmounting / (works according to mount status) > # fsck -p / # fails, apparently since acw is still nonzero > > In some non-current versions of FreeBSD, I have debugging code in > ffs_update() that complains about attempts to update inodes on read-only > file systems. Such attempts certainly occur, due to historical mistakes. > They are supposed to be handled (starting sometime in 4.x) by silently > ignoring the problem and clearing the IN_MODIFIED flag and related flags > so that the update is not retried later. I don't know of any cases where > this doesn't work. Does silently clearing that flag mean data could be lost? Or are these just async metadata updates and all the file content is properly flushed prior to the FS going RO? Thanks, Gary
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070704014205.GA53564>