Hi Mike, I've re-ordered a bit your mail to group some of my comments more logically.
> I am not sure a sysctl is a good mechanism for setting the mount default,
> especially if it is to be set via the kernel environment from
> /boot/loader.conf. That's an obscure place to find file system defaults.
If the setting has to matter for the root filesystem also (I think it should),
currently the knob should be set in '/boot/loader.conf'. But if "regular"
filesystems (those from '/etc/fstab') have an explicit 'atime' or 'noatime',
'/etc/sysctl.conf' could be enough ('/etc/rc/sysctl' is run very early).
> It also seems undesirable to add a sysctl to control a value that the
> kernel doesn't use.
The kernel has to use it to guarantee some uniform behavior irrespective of the
mount being performed through mount(8) or by a direct call to nmount(2). I
think this consistency is important. Perhaps all auto-mounters and mount
helpers always run mount(8) and never deal with nmount(2), I would have to
check (I seem to remember that, a long time ago, when nmount(2) was introduced
as an enhancement over mount(2), the stance was that applications should use
mount(8) and not nmount(2) directly). Even if there were no obvious callers of
nmount(2), I would be a bit uncomfortable with this discrepancy in behavior.
> Note that the root file system is mounted specially in the kernel, but the
> noatime option doesn't need to be set at first while the root is read-only.
> It could be updated by mount when remounting read-write from the startup
> scripts.
That's true. However, how about other filesystems mounted by rc scripts, such
as '/tmp'? I agree that this one is not a good example, since the 'tmpfs'
script ultimately calls 'mdmfs', which ultimately spawns a new process to
execute mount(8). But I fear that, if we don't have the consistency exposed
just above, we are going to need to audit other programs, including external
ones, which is precisely what I wanted to avoid with a simple default that
applies to everything (hence, implemented in the kernel).
> Instead, I'd like to propose that the default be
> specified in a new entry in /etc/fstab, where it would be much more obvious.
> For example, a line could be placed at the beginning like:
>
> # Device Mountpoint FStype Options
> default none default noatime,...
>
> It could be retrieved with getfsspec("default") in the fs_mnntops field.
> I wouldn't include this entry when iterating through the whole file with
> getfsent() to avoid confusing existing programs. Then mount, and other
> utilities such as zfs create, could check it explicitly. It should be
> placed in /etc/fstab when it is created: by bsdinstall when it is used,
> preferably by having the user select this explicitly, but probably with
> noatime being the default. It would be in the pre-configured fstab used
> for VM images and SD card images. Anyone building a root file system by
> hand would have to deal with this to set a default.
That could be great. And it's not necessarily in contradiction with a sysctl.
If we have the latter, setting the default could happen through it and could be
done by some startup script. Then, the only thing not covered is the root
filesystem, but even this is fixable by parsing the default line from the
loader itself (it already parses '/etc/fstab' after all) and converting that
specification to tunables passed to the kernel.
> I would then have the mount program look up and apply the default for things
> like mounting a file system manually. Perhaps it could have a -D option
> to ignore defaults, e.g. for scripts that don't want to be subject to local
> settings.
This is a complication in the case of using sysctl knobs and the kernel being
in charge of applying them as the defaults. It implies that mount(8) should
know some fixed old defaults, irrespective of the sysctl values. As evoked in
another mail, I think the choice of defaults is really an administrative
matter. If some scripts really need 'atime' to work, I would think that the
administrator should not change the default to 'noatime', else make sure these
scripts explicitly pass 'atime' (or use a line in '/etc/fstab' that specifies
'atime'). Doing the latter seems to be exactly the same effort as having the
same scripts start to use '-D' (whether by configuration or direct
modification).
> It would be plausible to set the default(s) in rc.conf instead, although
> that is more convenient for shell scripts than C programs. It would be
> possible to read output from something like "sysrc filesystem_defaults".
> It would also not be as obvious when setting or checking file system
> configuration.
The non-obvious remark seems to be an argument in favor of having the defaults
in '/etc/fstab'.
> btw, I think there is consensus that noatime is the most useful setting for
> most systems and users. However, I don't think there is consensus that the
> default should be changed for things like mount with no options. I think
> that putting a default somewhere fairly obvious could make it more palatable
> (less POLA violation). Opinions may vary, though.
To be clear, when you say mounting without options, there are two cases with
mount(8):
- Either a single argument referencing some line in '/etc/fstab', which could
well specify an explicit 'noatime' or 'atime', in which case of course it
should apply, not the global default. If the fstab line doesn't specify either
one, should the global default apply? For consistency and simplicity, I think
it should.
- A device and a mount point, in which case I don't see why the default
shouldn't apply.
If the default is controlled by a sysctl, it's an administrator setting, and
only an opt-in one as long as we don't change the sysctl's default value.
Simplicity and consistency are key to make this mechanism useful.
Administrators should not be put in a position where which options are going to
be applied is not obvious to them. Once they have set the sysctl, not always
obeying it is what I would think is the real POLA violation. What would be the
reasons to depart from this scheme?
Thanks and regards.
--
Olivier Certner
signature.asc
Description: This is a digitally signed message part.
