At 8:20 PM +0700 11/8/01, Robert Elz wrote:

>  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.

	I agree that the superblock should be recording the way 
things were done, but I disagree that the superblock should not be 
recording the way we want things to be done.

	Right now, I understand there is just one bit used for both 
under FreeBSD (which I believe is a mistake), whereas NetBSD (and 
presumably OpenBSD) use the bit for the recording purpose.  I believe 
that there should be two separate bits used for these two functions.

>  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.

	Conversely, in some cases I believe that you want the same 
value to be used every time for a particular filesystem, regardless 
of what /etc/fstab may say.

	This is a lowest common denominator issue.  Consider media 
being shared amongst multiple systems -- some implement soft updates, 
some don't.  Of those that do, some implement soft updates by 
default, and some don't.

	If you don't have a bit in the superblock to indicate where 
you want soft updates enabled (or not), and whether soft updates was 
actually enabled on this filesystem the last time it was mounted, 
then you've got a problem if there is a crash on a filesystem on a 
machine where soft updates was enabled on a filesystem (perhaps by 
default) and then for recovery purposes, you may need to move it to a 
system where soft updates is not built into the kernel -- the version 
of fsck on this recovery machine may not know how to deal with the 
particular types of filesystem problems left behind by soft updates.

	So long as soft updates is never enabled by default, then 
using a single bit to record whether or not soft updates ever was 
actually enabled should be okay -- at least those systems which don't 
know about soft updates can simply reject the attempt to mount that 
filesystem.  However, the moment you make soft updates enabled by 
default on some systems, you need an extra bit to indicate whether or 
not you want soft updates enabled on a particular filesystem, because 
this desire for soft updates being enabled or disabled may not be in 
sync with the /etc/fstab entry as a result of the filesystem being 
moved around between systems.

	Kirk really was thinking ahead here.

>  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.)

	I disagree.  None of these are types that are explicitly 
intended to go away in the near future.  Contrariwise, soft updates 
is precisely a method that is intended to be implemented by default 
in the future, and therefore it should "go away" as far as mount is 
concerned.

>  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).

	I believe that they implemented a "nosoftdep" option to mount 
with the same code change that allowed for the "softdep" option.

>  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.

	Correct.  I believe that this sort of option is something 
that needs to be "sticky" across kernel updates, and shouldn't 
require that any changes need to be made to /etc/fstab once soft 
updates becomes the default.

>  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.

	I disagree.  I think this argument shows the superiority of 
the tunefs method, something which is easy to integrate into the 
install process.  The only remaining problem is for the machines 
which were installed during the transition, and they should remain 
unchanged from their current configuration unless the administrator 
explicitly chooses to change their configuration after updating the 
kernel.

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

	This is just where we happened to run into the topic. 
Someone started talking about enabling soft updates on NetBSD using 
mount or /etc/fstab, and I asked if anyone had ever talked to Kirk as 
to his arguments for doing it with tunefs instead.

-- 
Brad Knowles, <brad.knowles@skynet.be>

H4sICIFgXzsCA2RtYS1zaWcAPVHLbsMwDDvXX0H0kkvbfxiwVw8FCmzAzqqj1F4dy7CdBfn7
Kc6wmyGRFEnvvxiWQoCvqI7RSWTcfGXQNqCUAnfIU+AT8OZ/GCNjRVlH0bKpguJkxiITZqes
MxwpSucyDJzXxQEUe/ihgXqJXUXwD9ajB6NHonLmNrUSK9nacHQnH097szO74xFXqtlbT3il
wMsBz5cnfCR5cEmci0Rj9u/jqBbPeES1I4PeFBXPUIT1XDSOuutFXylzrQvGyboWstCoQZyP
dxX4dLx0eauFe1x9puhoi0Ao1omEJo+BZ6XLVNaVpWiKekxN0VK2VMpmAy+Bk7ZV4SO+p1L/
uErNRS/qH2iFU+iNOtbcmVt9N16lfF7tLv9FXNj8AiyNcOi1AQAA