Subject: Re: Question about activating SoftUpdates.
To: Brad Knowles <brad.knowles@skynet.be>
From: Robert Elz <kre@munnari.OZ.AU>
List: port-sparc
Date: 11/08/2001 20:20:14
    Date:        Thu, 8 Nov 2001 11:50:53 +0100
    From:        Brad Knowles <brad.knowles@skynet.be>
    Message-ID:  <a05100305b81012390f32@[194.78.144.27]>

  | 	In addition, every single argument I've seen so far 
  | supporting the mount option or /etc/fstab solution I have found to be 
  | exceptionally lacking in understanding of the depth and nature of the 
  | problem.  I've heard Kirk's arguments on this matter, and I find them 
  | very compelling.  Indeed, I believe I've been able to come up with 
  | some of my own arguments supporting his position.

I certainly understand Kirk's position on this, more options to mount
are needed just about as much as more options to ls.

But in this case, I think he's wrong.

The filesystem should be recording its current state, that is the
attributes that currently apply (including whether it is currently
mounted with soft updates or not, so fsck knows what to do after a
crash).

It shouldn't be recording the desires of the operator for how to mount
it next time.

eg: the filesystem records where it is currently mounted - but we certainly
don't expect the "mount on" arg to mount to be made redundant by that,
where I want to mount it next time, and where I had it mounted last time
are unrelated concepts, even if they're very often the same value.

The same is true of the "how to I mount" (and if requesting soft update
mounts was correctly done by a tunefs option, then so should requesting
async mounts, or sync mounts.)

The best of the arguments (aside from the "too many options already")
for doing this as filesystem state, is the one that relates to what
happens when we want soft update mounts to become the default.

This, I think, points out a deficiency in the current NetBSD (probably
others) set of mount options.

That is, we currently have 4 ways to mount a FFS filesystem, async,
sync, soft-updates, and that other way...

The problem is that we have no label for "that other way", it is just
what we get when we don't ask for one of the others.   Keeping it like
this means that if we were to switch NetBSD to use soft updates by default,
we'd have no way really to get the current default way instead (we would
currently probably require "nosoft" as a mount option, but that's ugly,
and still doesn't actually say what we do want).

With the tunefs approach, when soft updates become default, they will
(I assume) only default on filesystems made after the switch - old,
untuned,  filesystems will keep operating the old way.   With the NetBSD
approach, when the default is switched, all mounts will switch with
the kernel - as no-one goes about saying "nosoft,nosync,noasync" in their
list of mount options...

This isn't an argument for switching back to the tunefs method, rather it
is a suggestion that we add a new name for our current set of mounts, and
start suggesting that people explicitly say what mount type they want for
all filesystem mounts (in fstab).   Once some leeway has been given, I
wouldn't even mind making this a mandatory option.

kre

ps: I can't even begin to imagine what this has to do with port-sparc...