Re: noatime on ufs2

On Mon, Jan 29, 2024 at 2:31 PM Olivier Certner <olce@freebsd.org> wrote:

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

I strongly oppose this notion to control this from loader.conf. Root is
mounted read-only, so it doesn't matter. That's why I liked Mike's
suggestion: root isn't special.


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

I disagree. I think Mike's suggestion was better and dealt with POLA and
POLA breaking in a sane way. If the default is applied universally in user
space, then we need not change the kernel at all. We lose all the chicken
and egg problems and the non-linearness of the sysctl idea.


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

If it's in fstab as default, then it would be read by whatever updates
things in user space.


> > 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 really like Mike's idea. It obviates the need for the sysctl entirely. It
gets around the need to update loader.conf as well. It concentrates the
change in one place and
does so in a way that's not at all atime focused:  It could also be
generalized so that the FSTYPE could have different settings for different
types of filesystem (maybe unique flags that some file systems don't
understand).



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

I don't like this, because it is atime focused. atime is a trivial little
optimization that really isn't worth the effort for the vast majority of
things. However, it would be nice to have some way to specify another layer
of defaults, like we do for rc variables, loader variables, etc. mount is
currently missing that generality. One could also put it in
/etc/defaults/fstab too and not break POLA since that's the pattern we use
elsewhere.


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

I don't think the case for sysctl has been made. It's a big, inelegant
hammer that can be solved more elegantly like Mike suggested. And it can be
used for more than just atime: it can be used for any option or set of
options you want. It's agnostic to why you want to do it. It follows the
'tools not rules' philosophy the project has had for decades.

Anyway, I've said my piece. I agree with Mike that there's consensus for
this from the installer, and after that consensus falls away. Mike's idea
is one that I can get behind since it elegantly solves the general problem.

Warner


> Thanks and regards.
>
> --
> Olivier Certner