Re: noatime on ufs2

Hi Mark,

> I never use atime, always noatime, for UFS. That said, I'd never propose
> changing the long standing defaults for commands and calls.

With this mail, you're giving more detailed objections on the social/political aspects of the proposed changed, or as we usually say more simply, POLA.

All your points are already largely weakened by the fact that, to wrap-up in a single sentence at the risk of being slightly caricatural (but then see my other mails), nobody really seems to care seriously about access times.

Please read my response to Rick Macklem on POLA, it is already a general answer to all of them.

Additionally, I have some specific answers or remarks.

> I'd avoid:

> A) Having natives & required file systems with mismatching defaults.
>     ("required" is for spanning efi/msdosfs partitions if the atime/noatime
>     makes a distinction there. So not just UFS/FFS and ZFS.)

The proposed change is general to the system, irrespective of partition types or mount points, so it doesn't have this problem.

> B) Having files systems that are not OS specific have unusual defaults
>     compared to those other OS's when there is documented uniformity.
>     (openzfs being such an example file system.)

The only example I think you can have of this is ZFS, and contrary to what you think is in fact not a problem because of its peculiarities.

ZFS stores 'atime' as a filesystem attribute ("property").  It automatically uses its (boolean) value at mount, unless overridden by explicit mount options, so no default value is relevant here.

Properties of a dataset are inherited from parents if not set explicitly (well, this is not true for statistics native properties, but 'atime' is not one of them, it is a control one).  So, if the value of 'atime' is reported by ZFS for some dataset as coming from a "default" source, necessarily the root dataset is using the same value.  Consequently, the only place where the default value (as seen by ZFS) matters is the root dataset.

Thus, the only sensible meaning of "having 'noatime' as the default behavior" for ZFS amounts to setting the 'atime' property to off on the root dataset on zpool creation.  By doing so, all datasets will inherit the value, unless explicitly overriden.  After the zpool creation, each dataset's value of 'atime' cannot be influenced by the system default at all, as is the case for all other similar properties (this is the way ZFS works).  In this scheme, it is necessary that OpenZFS keeps its own default value, in case ZFS pools created on other systems are imported on FreeBSD.  The only change with respect to current pools is that 'zfs get atime' on the root dataset will return a 'local' source instead of 'default'.  And that's all.  No change is necessary in ZFS.

> C) Having defaults unlike most other closely related operating systems
>     that support the file system when there is generally documented
>     uniformity. (No claim to have checked on the uniformity generally.)
>     (Other BSDs, Unix, Linux, . . .)

I didn't check these, but I would bet they all activate 'atime' by default, for "historical reasons".  I understand the fear here would be cognitive burden, but again in most cases it won't happen in practice.  If you take again the 3 cases developed in the response to Rick, you'll see that only people who really care about having 'atime' are concerned and should change their habits, and so far it seems it's by far the smallest group, and with no significant/compelling use case.  People who want 'noatime' and are used to using it can continue to do so without any change.  People who don't care, well... don't care.

> D) Having defaults for non-native files systems that are different than
>     the native contexts for the file system have when they have uniformity.
>     (So, for example, linux ext4 use would get linux etx4 default behavior
>      for atime vs. noatime if such is basically uniform across most
>      linux's.)

This point is an additional reason why the default should be per system and not by filesystem.

As I was writing the word "system", with its ambiguity (does it mean an operating system, or a particular machine?), I've just had another, simple idea: Create a system-wide sysctl knob controlling the default.  This would already allow administrators that care to set the value they want in a single place, and not have to tweak the mount point options, the configuration of auto-mounters and other applications mounting filesystems.  This doesn't say anything on the problem of FreeBSD's default value, which then becomes that of the default value for the knob.  However, the availability of the knob, besides its own usefulness, may convince reluctant people, which logically should be those that care about 'atime', to accept 'noatime' as the default, since it would become easier for them to override it back.

> Unless openzfs manges to decide to change that default across OSs,
> in my view FreeBSD should have it be left as documented for its use
> of openzfs. Given that, having FreeBSD UFS/FFS be the other way
> would be problematical in my view, even ignoring defaults for
> non-FreeBSD that support UFS/FFS use.

Showed above to be a non-problem, see point B).

Thanks and regards.

-- 
Olivier Certner