Date: Wed, 4 Jul 2007 11:08:36 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: David Cecil <david.cecil@nokia.com> Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org> Subject: Re: FFS writes to read-only mount Message-ID: <20070704102358.W95084@delplex.bde.org> In-Reply-To: <4689EFAA.4080009@nokia.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070704102358.W95084>