Date: Wed, 22 May 1996 15:28:21 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: randy@zyzzyva.com (Randy Terbush) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mount() flags Message-ID: <199605222228.PAA05227@phaeton.artisoft.com> In-Reply-To: <199605221658.LAA01473@sierra.zyzzyva.com> from "Randy Terbush" at May 22, 96 11:58:15 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Could someone offer some feedback about the following scenario,
> and perhaps some clues about the flags MNT_UPDATE and MNT_RELOAD?
> These flags aren't mentioned in the manpage.
OK. There's some magic embedded here for booting from an unclean
root so that you can fsck it.
> I have the following snippet of code. What I am trying to do is
> change a read-only mounted filesystem to read-write, change something
> on the filesystem, then remount read-only. This seems to cause
> a system panic, (details currently unavailable).
There's a couple bugs with the remount read-only having to do
with buffer flushing. Some of the FS patched I submitted, when
take with Matt Day's patches for the fs_sync code, fix the problem.
The patches were actually cooperatively evolved so that you could
mount the drives R/O and convert them to R/W instead of mounting
them R/W initially. This was actually to remove the BSD kernel
dependencies from the FS framework code to allow it to be used
from a Window95 IFS interface. It had the side effect of cleaning
up a lot of bogosities and allowing a lot of Windows95/WindowsNT
autoregocnition and PnP event-based technologies to be used in the
BSD kernel.
There are really two reasons behind this:
1) FS autorecognition requires the mount to go through, but
you don't necessarily want to change on disk structure as
a result. So you mount R/O and then convert when the FS
is mapped into the system hierarchy, but not before.
2) The sync code wanted to be modified to set the clean flag
on the FS after the sync had completed and no buffers were
there to allow DOS "power off" behaviour to not damage the
FS contents, requiring a fsck.
It turns out that the second of these results in the ability to
convert a R/W FS to a R/O FS, since that fag was the marker used
in the implementation to tag FS's which needed the clean bit
unset before an update could occur (this isn't quite what you
want in a FreeBSD kernel, where autoconversion from R/O to R/W
could be a bad thing -- you need another flag on the in core
mount struct for that).
As it happens, this was actually later removed in favor of getting
rid of the auto-clean feature and replacing it with a UFS specific
version of the Soft Updates code (which seems to be working fine;
Matt is a stud).
Jeffrey Hsu has just finished the Lite2 code integration; I haven't
had time to look it over yet like he's asked me to (just found out
about it 5 minutes ago). I'm pretty sure that he's done the right
thing, even without looking at it.
If it includes some of my UFS (and other FS) mount code changes,
the remount as R/O should work fine now.
This code is not currently available, and probably bears more testing
before it can be integrated into the common source tree.
> Trying to duplicate the problem with a floppy device I am finding
> that it looks as though these types of requests don't get queued.
> It would also appear that I may be in for a challenge to figure
> out how to wait for the first to finish.
I would suggest full unmounting and then remounting instead of converting
the mount type, at least for right now. If you run -current, it will
be at *least* several weeks before the modified code is generally
available, if then.
> Suggestions for the clueless are welcome.
>
>
> In the case below, the second call to mount will fail
> since the first call is still in progress. Is there a
> way to wait() on the first call?
stat( "/mnt", &statbuf1);
if ((mount (MOUNT_UFS, "/mnt", MNT_UPDATE, ufs)) != 0) {
fprintf (stderr, "failed to change mount status\n");
perror ("mount");
}
for(;;) {
stat( "/mnt", &statbuf2);
if( statbuf2.st_dev != statbuf1.st_dev)
break;
sleep( 1);
}
...
Will wait for the mount to complete.
I thought the call was synchronus, in any case... I think you are
really wanting to wait for no active buffers on the FS -- which is
something the current code can't support without an active unmount.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605222228.PAA05227>