Re: noatime on ufs2
On Tue, Jan 30, 2024 at 2:57 PM Mike Karels wrote:
>
> On 30 Jan 2024, at 15:48, Cy Schubert wrote:
>
> > In message > om>
> > , Rick Macklem writes:
> >> On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels
> >> wrot=
> >> e:
> >>>
> >>> On 30 Jan 2024, at 3:00, Olivier Certner wrote:
> >>>
> Hi Warner,
>
> > I strongly oppose this notion to control this from loader.conf. Root i=
> >> s
> > mounted read-only, so it doesn't matter. That's why I liked Mike's
> > suggestion: root isn't special.
>
> Then in fact there is nothing to oppose. You've just said yourself tha=
> >> t root is mounted first read-only. As Mike already said, it is remounted
> >> r=
> >> /w in userland later in the boot process. I just re-checked the code,
> >> beca=
> >> use I only had a vague recollection of all this, and can confirm.
>
> I mentioned the need to modify '/etc/loader.conf' as a possible consequ=
> >> ence, not as a goal. Given what we have established, there is no need to
> >> c=
> >> hange it at all.
>
> The root FS is thus in no way more special in the sysctl proposal than =
> >> with Mike's (assuming it doesn't rely on sysctl), this is an independent
> >> pr=
> >> operty due to the boot process design.
> >>>
> >>> With the possible exception that the sysctl mechanism might then have to
> >>> apply to mount update.
> >>>
> >>> It also seems undesirable to add a sysctl to control a value that th=
> >> e
> >>> kernel doesn't use.
> >>
> >> The kernel has to use it to guarantee some uniform behavior irrespect=
> >> ive
> >> 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 wi=
> >> th
> >> nmount(2), I would have to check (I seem to remember that, a long tim=
> >> e ago,
> >> when nmount(2) was introduced as an enhancement over mount(2), the st=
> >> ance
> >> 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.
> >>>
> >>> Based on a quick git grep, it looks like most of the things in base use
> >>> nmount(2), not mount(2). If they use mount(8), then it's not a problem
> >>> because mount(8) would be the first thing to get things right. If, by
> >>> mount helpers, you mean things like mount_nfs and mount_mfs, then mount(8=
> >> )
> >>> uses them rather than the reverse. I also don't remember any admonition
> >>> not to use nmount(2). mount(8) has a limited set of file system types th=
> >> at
> >>> it handles directly.
> >>>
> > I disagree. I think Mike's suggestion was better and dealt with POLA a=
> >> nd
> > POLA breaking in a sane way. If the default is applied universally in =
> >> user
> > space, then we need not change the kernel at all.
>
> I think applying the changes to userland only is really a bad idea. I'=
> >> ve already explained why, but going to do it again in case you missed
> >> that.=
> >> If you have counter-arguments, fine, but I would like to see them.
>
> Changing userland only causes a discrepancy between mount(8) and nmount=
> >> (2). Even if the project would take a stance that nmount(2) is not a
> >> publi=
> >> c API and mount(8) must always be used, the system call will still be
> >> there=
> >> And if it's not supposed to be used, what's the problem with changing it=
> >> as well?
> >>>
> >>> I don't think that stance has been taken; nmount(2) is certainly document=
> >> ed.
> >>> But I think that user level changes are required in both cases. First, f=
> >> or
> >>> the kernel to do the right thing, it needs to know if either noatime or a=
> >> time
> >>> has been specified explicitly, or if the default should apply. Otherwise=
> >> , the
> >>> kernel can only force noatime to be used in all cases or none, which I be=
> >> lieve
> >>> is a non-starter. Second, for anything using mount(2), the flags include=
> >> only
> >>> MNT_NOATIME, which can only include two options, not the required three. =
> >> It
> >>> would be possible to add another flag meaning to actually use the state o=
> >> f the
> >>> MNT_NOATIME flag, but that would require user-level changes. Third, if I
> >>> understand correctly, mount(8) parses the options and condenses the stand=
> >> ard
> >>> boolean options like {,no}atime into a bit, preserving the last option
> >>> specified. E.g. if the fstab lists noatime for a file system, and "mount=
> >> -o
> >>> atime ..." is given on the command line, noatime will not be included in
> >>> the kernel options. The kernel can't tell why, whether nothing was speci=
> >> fied
> >>> or the option was explicit. In theory, three states can be encoded using
> >>> nmount; options could include "atime",
Re: noatime on ufs2
In message <3f6cf45c-3d34-4da6-9b81-337eb70bb...@karels.net>, Mike Karels
write
s:
> On 30 Jan 2024, at 15:48, Cy Schubert wrote:
>
> > In message c
> > om>
> > , Rick Macklem writes:
> >> On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels wro
> t=
> >> e:
> >>>
> >>> On 30 Jan 2024, at 3:00, Olivier Certner wrote:
> >>>
> Hi Warner,
>
> > I strongly oppose this notion to control this from loader.conf. Root i=
> >> s
> > mounted read-only, so it doesn't matter. That's why I liked Mike's
> > suggestion: root isn't special.
>
> Then in fact there is nothing to oppose. You've just said yourself tha=
> >> t root is mounted first read-only. As Mike already said, it is remounted
> r=
> >> /w in userland later in the boot process. I just re-checked the code, bec
> a=
> >> use I only had a vague recollection of all this, and can confirm.
>
> I mentioned the need to modify '/etc/loader.conf' as a possible consequ=
> >> ence, not as a goal. Given what we have established, there is no need to
> c=
> >> hange it at all.
>
> The root FS is thus in no way more special in the sysctl proposal than =
> >> with Mike's (assuming it doesn't rely on sysctl), this is an independent p
> r=
> >> operty due to the boot process design.
> >>>
> >>> With the possible exception that the sysctl mechanism might then have to
> >>> apply to mount update.
> >>>
> >>> It also seems undesirable to add a sysctl to control a value that th=
> >> e
> >>> kernel doesn't use.
> >>
> >> The kernel has to use it to guarantee some uniform behavior irrespect=
> >> ive
> >> 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 wi=
> >> th
> >> nmount(2), I would have to check (I seem to remember that, a long tim=
> >> e ago,
> >> when nmount(2) was introduced as an enhancement over mount(2), the st=
> >> ance
> >> 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.
> >>>
> >>> Based on a quick git grep, it looks like most of the things in base use
> >>> nmount(2), not mount(2). If they use mount(8), then it's not a problem
> >>> because mount(8) would be the first thing to get things right. If, by
> >>> mount helpers, you mean things like mount_nfs and mount_mfs, then mount(8
> =
> >> )
> >>> uses them rather than the reverse. I also don't remember any admonition
> >>> not to use nmount(2). mount(8) has a limited set of file system types th
> =
> >> at
> >>> it handles directly.
> >>>
> > I disagree. I think Mike's suggestion was better and dealt with POLA a=
> >> nd
> > POLA breaking in a sane way. If the default is applied universally in =
> >> user
> > space, then we need not change the kernel at all.
>
> I think applying the changes to userland only is really a bad idea. I'=
> >> ve already explained why, but going to do it again in case you missed that
> .=
> >> If you have counter-arguments, fine, but I would like to see them.
>
> Changing userland only causes a discrepancy between mount(8) and nmount=
> >> (2). Even if the project would take a stance that nmount(2) is not a publ
> i=
> >> c API and mount(8) must always be used, the system call will still be ther
> e=
> >> And if it's not supposed to be used, what's the problem with changing it
> =
> >> as well?
> >>>
> >>> I don't think that stance has been taken; nmount(2) is certainly document
> =
> >> ed.
> >>> But I think that user level changes are required in both cases. First, f
> =
> >> or
> >>> the kernel to do the right thing, it needs to know if either noatime or a
> =
> >> time
> >>> has been specified explicitly, or if the default should apply. Otherwise
> =
> >> , the
> >>> kernel can only force noatime to be used in all cases or none, which I be
> =
> >> lieve
> >>> is a non-starter. Second, for anything using mount(2), the flags include
> =
> >> only
> >>> MNT_NOATIME, which can only include two options, not the required three.
> =
> >> It
> >>> would be possible to add another flag meaning to actually use the state o
> =
> >> f the
> >>> MNT_NOATIME flag, but that would require user-level changes. Third, if I
> >>> understand correctly, mount(8) parses the options and condenses the stand
> =
> >> ard
> >>> boolean options like {,no}atime into a bit, preserving the last option
> >>> specified. E.g. if the fstab lists noatime for a file system, and "mount
> =
> >> -o
> >>> atime ..." is given on the command line, noatime will not be included in
> >>> the kernel options. The kernel can't tell why, whether nothing was speci
> =
> >> fied
> >>> or the option was explicit. In theory, three states can be encoded using
Re: noatime on ufs2
On 30 Jan 2024, at 15:48, Cy Schubert wrote:
> In message om>
> , Rick Macklem writes:
>> On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels wrot=
>> e:
>>>
>>> On 30 Jan 2024, at 3:00, Olivier Certner wrote:
>>>
Hi Warner,
> I strongly oppose this notion to control this from loader.conf. Root i=
>> s
> mounted read-only, so it doesn't matter. That's why I liked Mike's
> suggestion: root isn't special.
Then in fact there is nothing to oppose. You've just said yourself tha=
>> t root is mounted first read-only. As Mike already said, it is remounted r=
>> /w in userland later in the boot process. I just re-checked the code, beca=
>> use I only had a vague recollection of all this, and can confirm.
I mentioned the need to modify '/etc/loader.conf' as a possible consequ=
>> ence, not as a goal. Given what we have established, there is no need to c=
>> hange it at all.
The root FS is thus in no way more special in the sysctl proposal than =
>> with Mike's (assuming it doesn't rely on sysctl), this is an independent pr=
>> operty due to the boot process design.
>>>
>>> With the possible exception that the sysctl mechanism might then have to
>>> apply to mount update.
>>>
>>> It also seems undesirable to add a sysctl to control a value that th=
>> e
>>> kernel doesn't use.
>>
>> The kernel has to use it to guarantee some uniform behavior irrespect=
>> ive
>> 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 wi=
>> th
>> nmount(2), I would have to check (I seem to remember that, a long tim=
>> e ago,
>> when nmount(2) was introduced as an enhancement over mount(2), the st=
>> ance
>> 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.
>>>
>>> Based on a quick git grep, it looks like most of the things in base use
>>> nmount(2), not mount(2). If they use mount(8), then it's not a problem
>>> because mount(8) would be the first thing to get things right. If, by
>>> mount helpers, you mean things like mount_nfs and mount_mfs, then mount(8=
>> )
>>> uses them rather than the reverse. I also don't remember any admonition
>>> not to use nmount(2). mount(8) has a limited set of file system types th=
>> at
>>> it handles directly.
>>>
> I disagree. I think Mike's suggestion was better and dealt with POLA a=
>> nd
> POLA breaking in a sane way. If the default is applied universally in =
>> user
> space, then we need not change the kernel at all.
I think applying the changes to userland only is really a bad idea. I'=
>> ve already explained why, but going to do it again in case you missed that.=
>> If you have counter-arguments, fine, but I would like to see them.
Changing userland only causes a discrepancy between mount(8) and nmount=
>> (2). Even if the project would take a stance that nmount(2) is not a publi=
>> c API and mount(8) must always be used, the system call will still be there=
>> And if it's not supposed to be used, what's the problem with changing it=
>> as well?
>>>
>>> I don't think that stance has been taken; nmount(2) is certainly document=
>> ed.
>>> But I think that user level changes are required in both cases. First, f=
>> or
>>> the kernel to do the right thing, it needs to know if either noatime or a=
>> time
>>> has been specified explicitly, or if the default should apply. Otherwise=
>> , the
>>> kernel can only force noatime to be used in all cases or none, which I be=
>> lieve
>>> is a non-starter. Second, for anything using mount(2), the flags include=
>> only
>>> MNT_NOATIME, which can only include two options, not the required three. =
>> It
>>> would be possible to add another flag meaning to actually use the state o=
>> f the
>>> MNT_NOATIME flag, but that would require user-level changes. Third, if I
>>> understand correctly, mount(8) parses the options and condenses the stand=
>> ard
>>> boolean options like {,no}atime into a bit, preserving the last option
>>> specified. E.g. if the fstab lists noatime for a file system, and "mount=
>> -o
>>> atime ..." is given on the command line, noatime will not be included in
>>> the kernel options. The kernel can't tell why, whether nothing was speci=
>> fied
>>> or the option was explicit. In theory, three states can be encoded using
>>> nmount; options could include "atime", "noatime", or neither. But that's
>>> not what the current user level does, so changes are required. Given tha=
>> t,
>>> it makes the most sense to have mount(8) and others to incorporate the
>>> default into their operation, and just give the kernel the answer. btw,
>>> see mntopts(3) for where this code would
Re: noatime on ufs2
In message
, Rick Macklem writes:
> On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels wrot=
> e:
> >
> > On 30 Jan 2024, at 3:00, Olivier Certner wrote:
> >
> > > Hi Warner,
> > >
> > >> I strongly oppose this notion to control this from loader.conf. Root i=
> s
> > >> mounted read-only, so it doesn't matter. That's why I liked Mike's
> > >> suggestion: root isn't special.
> > >
> > > Then in fact there is nothing to oppose. You've just said yourself tha=
> t root is mounted first read-only. As Mike already said, it is remounted r=
> /w in userland later in the boot process. I just re-checked the code, beca=
> use I only had a vague recollection of all this, and can confirm.
> > >
> > > I mentioned the need to modify '/etc/loader.conf' as a possible consequ=
> ence, not as a goal. Given what we have established, there is no need to c=
> hange it at all.
> > >
> > > The root FS is thus in no way more special in the sysctl proposal than =
> with Mike's (assuming it doesn't rely on sysctl), this is an independent pr=
> operty due to the boot process design.
> >
> > With the possible exception that the sysctl mechanism might then have to
> > apply to mount update.
> >
> > It also seems undesirable to add a sysctl to control a value that th=
> e
> > kernel doesn't use.
> > >>>
> > >>> The kernel has to use it to guarantee some uniform behavior irrespect=
> ive
> > >>> 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 wi=
> th
> > >>> nmount(2), I would have to check (I seem to remember that, a long tim=
> e ago,
> > >>> when nmount(2) was introduced as an enhancement over mount(2), the st=
> ance
> > >>> 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.
> >
> > Based on a quick git grep, it looks like most of the things in base use
> > nmount(2), not mount(2). If they use mount(8), then it's not a problem
> > because mount(8) would be the first thing to get things right. If, by
> > mount helpers, you mean things like mount_nfs and mount_mfs, then mount(8=
> )
> > uses them rather than the reverse. I also don't remember any admonition
> > not to use nmount(2). mount(8) has a limited set of file system types th=
> at
> > it handles directly.
> >
> > >> I disagree. I think Mike's suggestion was better and dealt with POLA a=
> nd
> > >> POLA breaking in a sane way. If the default is applied universally in =
> user
> > >> space, then we need not change the kernel at all.
> > >
> > > I think applying the changes to userland only is really a bad idea. I'=
> ve already explained why, but going to do it again in case you missed that.=
> If you have counter-arguments, fine, but I would like to see them.
> > >
> > > Changing userland only causes a discrepancy between mount(8) and nmount=
> (2). Even if the project would take a stance that nmount(2) is not a publi=
> c API and mount(8) must always be used, the system call will still be there=
> And if it's not supposed to be used, what's the problem with changing it=
> as well?
> >
> > I don't think that stance has been taken; nmount(2) is certainly document=
> ed.
> > But I think that user level changes are required in both cases. First, f=
> or
> > the kernel to do the right thing, it needs to know if either noatime or a=
> time
> > has been specified explicitly, or if the default should apply. Otherwise=
> , the
> > kernel can only force noatime to be used in all cases or none, which I be=
> lieve
> > is a non-starter. Second, for anything using mount(2), the flags include=
> only
> > MNT_NOATIME, which can only include two options, not the required three. =
> It
> > would be possible to add another flag meaning to actually use the state o=
> f the
> > MNT_NOATIME flag, but that would require user-level changes. Third, if I
> > understand correctly, mount(8) parses the options and condenses the stand=
> ard
> > boolean options like {,no}atime into a bit, preserving the last option
> > specified. E.g. if the fstab lists noatime for a file system, and "mount=
> -o
> > atime ..." is given on the command line, noatime will not be included in
> > the kernel options. The kernel can't tell why, whether nothing was speci=
> fied
> > or the option was explicit. In theory, three states can be encoded using
> > nmount; options could include "atime", "noatime", or neither. But that's
> > not what the current user level does, so changes are required. Given tha=
> t,
> > it makes the most sense to have mount(8) and others to incorporate the
> > default into their operation, and just give the kernel the answer. btw,
> > see mntopts(3) for where this code would go.
> These days most mount options are parsed in the kernel
Re: noatime on ufs2
On Tue, Jan 30, 2024 at 10:49 AM Mike Karels wrote:
>
> On 30 Jan 2024, at 3:00, Olivier Certner wrote:
>
> > Hi Warner,
> >
> >> 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.
> >
> > Then in fact there is nothing to oppose. You've just said yourself that
> > root is mounted first read-only. As Mike already said, it is remounted r/w
> > in userland later in the boot process. I just re-checked the code, because
> > I only had a vague recollection of all this, and can confirm.
> >
> > I mentioned the need to modify '/etc/loader.conf' as a possible
> > consequence, not as a goal. Given what we have established, there is no
> > need to change it at all.
> >
> > The root FS is thus in no way more special in the sysctl proposal than with
> > Mike's (assuming it doesn't rely on sysctl), this is an independent
> > property due to the boot process design.
>
> With the possible exception that the sysctl mechanism might then have to
> apply to mount update.
>
> 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.
>
> Based on a quick git grep, it looks like most of the things in base use
> nmount(2), not mount(2). If they use mount(8), then it's not a problem
> because mount(8) would be the first thing to get things right. If, by
> mount helpers, you mean things like mount_nfs and mount_mfs, then mount(8)
> uses them rather than the reverse. I also don't remember any admonition
> not to use nmount(2). mount(8) has a limited set of file system types that
> it handles directly.
>
> >> 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.
> >
> > I think applying the changes to userland only is really a bad idea. I've
> > already explained why, but going to do it again in case you missed that.
> > If you have counter-arguments, fine, but I would like to see them.
> >
> > Changing userland only causes a discrepancy between mount(8) and nmount(2).
> > Even if the project would take a stance that nmount(2) is not a public API
> > and mount(8) must always be used, the system call will still be there And
> > if it's not supposed to be used, what's the problem with changing it as
> > well?
>
> I don't think that stance has been taken; nmount(2) is certainly documented.
> But I think that user level changes are required in both cases. First, for
> the kernel to do the right thing, it needs to know if either noatime or atime
> has been specified explicitly, or if the default should apply. Otherwise, the
> kernel can only force noatime to be used in all cases or none, which I believe
> is a non-starter. Second, for anything using mount(2), the flags include only
> MNT_NOATIME, which can only include two options, not the required three. It
> would be possible to add another flag meaning to actually use the state of the
> MNT_NOATIME flag, but that would require user-level changes. Third, if I
> understand correctly, mount(8) parses the options and condenses the standard
> boolean options like {,no}atime into a bit, preserving the last option
> specified. E.g. if the fstab lists noatime for a file system, and "mount -o
> atime ..." is given on the command line, noatime will not be included in
> the kernel options. The kernel can't tell why, whether nothing was specified
> or the option was explicit. In theory, three states can be encoded using
> nmount; options could include "atime", "noatime", or neither. But that's
> not what the current user level does, so changes are required. Given that,
> it makes the most sense to have mount(8) and others to incorporate the
> default into their operation, and just give the kernel the answer. btw,
> see mntopts(3) for where this code would go.
These days most mount options are parsed in the kernel via vfs_getopts(),
but not "atime". It appears that "(no)atime" sets/clears MNT_NOATIME in
userspace via the getmntopts() function that lives in
/usr/src/sbin/mount/getmntopts.c.
I think this is mostly cruft left over from the mount(2)->nmount(2) conversion,
Re: noatime on ufs2
On 30 Jan 2024, at 3:00, Olivier Certner wrote:
> Hi Warner,
>
>> 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.
>
> Then in fact there is nothing to oppose. You've just said yourself that root
> is mounted first read-only. As Mike already said, it is remounted r/w in
> userland later in the boot process. I just re-checked the code, because I
> only had a vague recollection of all this, and can confirm.
>
> I mentioned the need to modify '/etc/loader.conf' as a possible consequence,
> not as a goal. Given what we have established, there is no need to change it
> at all.
>
> The root FS is thus in no way more special in the sysctl proposal than with
> Mike's (assuming it doesn't rely on sysctl), this is an independent property
> due to the boot process design.
With the possible exception that the sysctl mechanism might then have to
apply to mount update.
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.
Based on a quick git grep, it looks like most of the things in base use
nmount(2), not mount(2). If they use mount(8), then it's not a problem
because mount(8) would be the first thing to get things right. If, by
mount helpers, you mean things like mount_nfs and mount_mfs, then mount(8)
uses them rather than the reverse. I also don't remember any admonition
not to use nmount(2). mount(8) has a limited set of file system types that
it handles directly.
>> 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.
>
> I think applying the changes to userland only is really a bad idea. I've
> already explained why, but going to do it again in case you missed that. If
> you have counter-arguments, fine, but I would like to see them.
>
> Changing userland only causes a discrepancy between mount(8) and nmount(2).
> Even if the project would take a stance that nmount(2) is not a public API
> and mount(8) must always be used, the system call will still be there. And
> if it's not supposed to be used, what's the problem with changing it as well?
I don't think that stance has been taken; nmount(2) is certainly documented.
But I think that user level changes are required in both cases. First, for
the kernel to do the right thing, it needs to know if either noatime or atime
has been specified explicitly, or if the default should apply. Otherwise, the
kernel can only force noatime to be used in all cases or none, which I believe
is a non-starter. Second, for anything using mount(2), the flags include only
MNT_NOATIME, which can only include two options, not the required three. It
would be possible to add another flag meaning to actually use the state of the
MNT_NOATIME flag, but that would require user-level changes. Third, if I
understand correctly, mount(8) parses the options and condenses the standard
boolean options like {,no}atime into a bit, preserving the last option
specified. E.g. if the fstab lists noatime for a file system, and "mount -o
atime ..." is given on the command line, noatime will not be included in
the kernel options. The kernel can't tell why, whether nothing was specified
or the option was explicit. In theory, three states can be encoded using
nmount; options could include "atime", "noatime", or neither. But that's
not what the current user level does, so changes are required. Given that,
it makes the most sense to have mount(8) and others to incorporate the
default into their operation, and just give the kernel the answer. btw,
see mntopts(3) for where this code would go.
> Second, we can control what is in the base system, but not other
> applications, so we can't really prevent nmount(2) to be used.
>
> Some of the goals of my proposal include to simplifying things, both in terms
> of administration but also in terms of the amount of code, and to provide
> reliable behavior. My current evaluation is that changing userland will
> require more code changes than the sysctl I propose, and it has all the
> drawbacks I've just mentioned.
I think that all of the user code needs changes in
Re: noatime on ufs2
> In the current situation, I can back using '/etc/fstab', or probably better, > '/usr/local/etc/fstab' to hold default mount options, but I'm strongly > opposing a pure userland implementation as long as my objections above are > not addressed properly. Typo, '/usr/local/etc/fstab' should read '/etc/defaults/fstab'. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi Warner, > 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. Then in fact there is nothing to oppose. You've just said yourself that root is mounted first read-only. As Mike already said, it is remounted r/w in userland later in the boot process. I just re-checked the code, because I only had a vague recollection of all this, and can confirm. I mentioned the need to modify '/etc/loader.conf' as a possible consequence, not as a goal. Given what we have established, there is no need to change it at all. The root FS is thus in no way more special in the sysctl proposal than with Mike's (assuming it doesn't rely on sysctl), this is an independent property due to the boot process design. > > > 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. I think applying the changes to userland only is really a bad idea. I've already explained why, but going to do it again in case you missed that. If you have counter-arguments, fine, but I would like to see them. Changing userland only causes a discrepancy between mount(8) and nmount(2). Even if the project would take a stance that nmount(2) is not a public API and mount(8) must always be used, the system call will still be there. And if it's not supposed to be used, what's the problem with changing it as well? Second, we can control what is in the base system, but not other applications, so we can't really prevent nmount(2) to be used. Some of the goals of my proposal include to simplifying things, both in terms of administration but also in terms of the amount of code, and to provide reliable behavior. My current evaluation is that changing userland will require more code changes than the sysctl I propose, and it has all the drawbacks I've just mentioned. What I find great in Mike's proposal is to use '/etc/fstab' to control filesystem defaults, because '/etc/fstab' is already the go-to place for filesystems and already holds options to apply to particular mounts. But again, this is independent of where the mechanism is actually implemented. > We lose all the chicken and egg problems and the non-linearness of the sysctl > idea. As already said above, there is in the end no such problem, and it wasn't linked at all with the sysctl idea. On the contrary, with the '/etc/fstab' proposal, if there is no kernel backing, the loader must be modified to parse default options, and then pass them to the kernel (via 'vfs.root.mountfrom.options'), or the script remounting r/w be modified to apply the proper options (or 'mount -u' itself changed to do so). > If it's in fstab as default, then it would be read by whatever updates > things in user space. It's very unlikely that applications would not need modifications in this regard. Mike even said that he wouldn't have getfsent() return such entries to avoid confusing existing programs. Needing specific code makes this point moot (if you have to modify a program to read and process the special lines in '/etc/fstab', you can as well modify it to use sysctl(8)). The real advantage is direct modifications in a text file by an administrator, and this is why I like the '/etc/fstab' idea. > It obviates the need for the sysctl entirely. It doesn't obviate the need for a kernel mechanism (sysctl(8) or else), see argument on mount(8) and nmount(2) above. And once you need a kernel mechanism, sysctl(8) is most probably the best candidate for tunables (why re-invent the wheel?). > It gets around the need to update loader.conf as well. You keep repeating that, but it's false as explained above. > 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). You can also have this with a properly designed sysctl(8) hierarchy. > I don't like
Re: noatime on ufs2
Am 2024-01-30 01:21, schrieb Warner Losh: On Mon, Jan 29, 2024 at 2:31 PM Olivier Certner wrote: 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. I would like to add that a sysctl is some kind of a hidden setting, whereas /etc/fstab + /etc/defaults/fstab is a "right in the face" way of setting filesystem / mount related stuff. [...] 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). +1 nosuid for tmpfs comes into my mind here... One could also put it in /etc/defaults/fstab too and not break POLA since that's the pattern we use elsewhere. +1 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. +1 Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
Re: noatime on ufs2
On Mon, Jan 29, 2024 at 2:31 PM Olivier Certner 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:
> >
> > # DeviceMountpoint FStype Options
> > default nonedefault 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
Re: noatime on ufs2
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:
>
> # DeviceMountpoint FStype Options
> default nonedefault 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
Re: noatime on ufs2
Hi, > Let me start out by indicating that some bike shed sessions > (snip) > Much of the overall usage is in that "additional attempted span". Ok, so it seems I've misunderstood what you were saying or your intent in this regard. > I will adjust and deal with whatever happens > overall. That is something I know I can do for my > usage context. With a sysctl knob defaulting to 'atime', you won't have to change anything. Thanks for your participation. Regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
On Jan 29, 2024, at 02:27, Olivier Certner wrote: > Hi Mark, Hello. Let me start out by indicating that some bike shed sessions are useful overall, even if not contributing to crucial matters. I do not see withdrawing from continued participation with new material as disqualifying of any of the rest of the overall effort in a bike shed session. Given what has already occurred in the session, I've nothing significant to add to the accumulated material and am trying to avoid adding less significant material that wastes effort/time. >> I'm confused: I go to the trouble to produce the same end result >> as your suggested change of defaults would produce, ending up >> with no recording of access times. > > That's nice of you, but unfortunately that's missing the point. First, you > claimed to "seriously care" about access time, so I simply asked about your > use cases, which you have not talked about. Second, your suggestions do not > (in fact, cannot) produce the same end result as what I'm suggesting (change > of default, or have a sysctl to control the default). I've already listed > three use cases in an answer to Warner that can't be covered by modifying > '/etc/fstab', and two of them that can't by just specifying mount options to > mount(8) on the command-line (the auto-mounters). I tried pointing out that my limited usage context is too narrow to make a reasonable generalization from for the overall problem. Auto-mounting is a good example that I'll point out relative to my usage context: What auto-mounting? But auto- mounting should be considered. I had to try to span beyond my usage context to form the options that I expressed. To only consider my usage would have been inappropriate. I can not use my usage context to justify coverage of that additional attempted span. Much of the overall usage is in that "additional attempted span". I will adjust and deal with whatever happens overall. That is something I know I can do for my usage context. >> . . . > . . . > > Is 'noatime' not being the default the biggest problem we currently have in > FreeBSD? I agree it isn't. However, it doesn't mean there is no value in > it. On the contrary, I think it is very important that the project has sane > defaults that match contemporary uses: It reduces the need for tweaks, which > serves both beginners but *also* seasoned administrators. This is in > isolation a very small step in this direction, but there have been others and > more will come. Collectively, they can build up to significant additional > value for the project. === Mark Millard marklmi at yahoo.com
Re: noatime on ufs2
Not responding to a specific message, but following up on the thread:
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.
It also seems undesirable to add a sysctl to control a value that the
kernel doesn't use. 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:
# DeviceMountpoint FStype Options
default nonedefault 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.
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.
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.
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.
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.
Mike
Re: noatime on ufs2
Hi Chris, > Honestly! Gosh... This doesn't start well. > Why do we have to upend decades of usage and understanding? Just > because it's old doesn't mean it's wrong. Who says that exactly? Separately, in case you haven't noticed yet, some things have changed in the past 50 years... > Several weeks of replies confirm my initial > belief -- atime as it is currently implemented, is as it should be. Several weeks? The first mail was sent on January 7th, my first intervention about 'noatime' being the default was on the 9th and your mail is dated the 16th. I would suggest that you revise your implementation of access times. > I haven't seen anything in this thread that wouldn't be better placed in > tuning(7) or tunefs(8). It's not really surprising since, given what you said before that, it seems that you haven't really paid attention to the messages exchanged. > Security and forensics are good reasons to keep atime unchanged. Having access times maintained may occasionally provide a bit more information, especially against script kiddies. But if you think it's a reliable source of information, you're deluded. See my response to Lyndon about the general problem with access times. I also already talked about auditing's needs in my very first mail in this thread. > Any discussion regarding changes to it's current behavior seems folly or > bikeshedding. About bike shedding, see my recent response to Mark, it applies to "folly" as well. > Apologies for the "attitude". Yeah. Most prompts imagined by Poul-Henning Kamp in his bikeshed email would have applied perfectly to your message. Thanks for the thought. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi Mark, > I'm confused: I go to the trouble to produce the same end result > as your suggested change of defaults would produce, ending up > with no recording of access times. That's nice of you, but unfortunately that's missing the point. First, you claimed to "seriously care" about access time, so I simply asked about your use cases, which you have not talked about. Second, your suggestions do not (in fact, cannot) produce the same end result as what I'm suggesting (change of default, or have a sysctl to control the default). I've already listed three use cases in an answer to Warner that can't be covered by modifying '/etc/fstab', and two of them that can't by just specifying mount options to mount(8) on the command-line (the auto-mounters). > My focus was on things like mount command notation and > /etc/fstab notation (that tracks mount defaults) or subroutine > interface equivalents of such things and changing their > behavior without requiring changing the notation already in > place in various files. > Nothing about that of itself > implies that I'd want the defaults for mount notation or /etc/fstab > notation or the like changed --or that I'd want them unchanged. > To narrow of a context for such a judgment about defaults. These two paragraphs seem to contradict themselves. If you've gone to the trouble mentioned above, wasn't it precisely to avoid changing the defaults? Because changing them implies that the exact same mount(8) command-line or line in '/etc/fstab' will have a different effect if 'atime' nor 'noatime' aren't explicitly specified. This is a goal, not an unwanted side effect. > In case the potential confusion is involved I'm wondering if you might be confusing default options per mount (as a line in '/etc/fstab') and system defaults applying to all mounts. By design, the former can't apply to mounts not handled by '/etc/fstab'. The latter applies in any situation, barring explicit specifications by the administrator (or delegated software), which is why it belongs to the kernel (it has to apply to the relevant system calls). > (I've tried to word the above without making new points, > avoiding contributing more to the bike shed material.) Bike shedding has become so popular in these circles that some people see bike shedding where there is none, and/or use it as a tactic to try to disqualify what others are saying. The initial bike shedding email was about a simple, obvious change to sleep(1) that prompted a flame war lasting weeks, with unfriendly fire from the project's people, sometimes from the old timers. We haven't had much of that so far, except perhaps for a few mildly aggressive or emotional emails, and the thread was active for only 10 days. It was then paused for 12 days since I didn't find time to read the latest mails and produce answers until today. What sets it apart also from the sleep(1) example is that I intended to drop an idea and gather reactions before having even produced code, because I wasn't sure on how it would be received and in particular what are the use cases that could be affected. Obtaining this feedback is essential because this project is about people from diverse backgrounds and needs. It also helps in clarifying a particular design, which some answers fulfilled. I'm now at the point where the next step is to put up some code for review for a sysctl knob. Is 'noatime' not being the default the biggest problem we currently have in FreeBSD? I agree it isn't. However, it doesn't mean there is no value in it. On the contrary, I think it is very important that the project has sane defaults that match contemporary uses: It reduces the need for tweaks, which serves both beginners but *also* seasoned administrators. This is in isolation a very small step in this direction, but there have been others and more will come. Collectively, they can build up to significant additional value for the project. Regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi Alexander,
> ZFS by default has atime=on. It is our installer which sets atime=off in
> the ZFS properties. I was understanding Warners comment about changing
> ZFS in the sense of changing the ZFS code to have a default of
> atime=off.
>
> I agree with Warner that we should not do that. And in my opinion we
> should keep the other FS which support atime/noatime consistent (those
> which don't support atime/noatime due to technial limitations don't
> count in my opinion)
I've almost addressed this point in an analysis responding to a similar point
by Mark Millard, so let me wrap up and complete it.
The situation of ZFS is not comparable to that of other filesystems because ZFS
keeps a persistent "access time" setting (the 'atime' property) for its
filesystems. ZFS' fundamental way to deal with such kind of settings ("native
control properties") is to automatically apply them at mount, so changing that
part would indeed be a huge POLA violation, and I'm not proposing it (and, to
be clear, never meant to).
The only place where a system default for 'atime' makes sense for ZFS is the
initial value of 'atime' for the root filesystem of each pool on pool creation.
So it's really only a matter of, e.g., changing 'zpool create' to behave as if
'atime=on' or 'atime=off' were explicitly specified (depending on the sysctl's
value; of course, if the user really specified one or the other, his value
prevails). Doing it this way makes ZFS' default for 'atime' completely
invisible (a good thing, IMO). More importantly, after skimming through the
relevant code, it's likely it will work without any kernel code change (whether
in OpenZFS or FreeBSD) at all. There are also other possibilities.
> But I would say this is atypical behavior by people which know
> exactly what they are doing, not what a normal consumer would do. Such
> experts know exactly what they want to do with atime and handle it as
> needed.
The point is rather that nobody, even experts, should bother tuning mounts with
'noatime' when almost all people that care want 'noatime'.
> Those which care about that and know where this makes a difference, have
> it in their finger-memory.
Sure. Does this mean that they must be forced to specify it each time, or even
have scripts for that, each one developing its own? I don't see anything
constructive in requiring that.
> If they are not able to handle that, it is a bug.
> Typical media in desktop use-cases doesn't really need this. If you
> handle media which really _needs_ noatime in such a case, you may want
> to reconsider your way of operating.
I've already mentioned the case of buggy USB keys in another mail, which is a
very annoying use case. Of course, I try to avoid it, but as you know, these
things happen, and this has nothing to do with how I operate but just
adaptation to the world we live in.
> > So limiting action to the installer, while certainly a sensible and
> > pragmatic step, still seems to miss a lot.
>
> Nobody told to only limit this action to the installer.
This seemed to be implicit in some other answers, so I prefer to clarify.
> The pragmatic part here is to ask if it really matters for those use cases.
> For
> mounting by hand I disagree that it matters. For our automounter we
> should do something (at least making sure it is able to handle it, and
> if we don't want to swtich the default at least have a commented out
> entry in the config with a suitable comment). For the desktop helpers it
> is not our responsability, but interested people surely can file a bug
> report upstream.
I disagree for the mounting by hand part (whether to mount USB key or other
external disks). For the rest, yes, it would be nice to change our automounter
and external programs, but all of this becomes moot with a proper default, so
why go through that hassle for the case at hand?
> While I agree that this would be an easy way of globally changing the
> default, what makes noatime special compared to nocover, or nfs4acl, or
> noexec, or nosuid, or whatever other option? Mounting noexec and nosuid
> by default and having those FS be mounted explicitely suid/exec which
> really need it would be a security benefit. And cover/nocover would
> prevent accidental foot-shooting. Where do you want to draw the line
> between "easy" and "explicit"? Only having atime/noatime handled like
> that looks inconsistent to me (which - I hope - not only me thinks is a
> POLA violation).
I'd say this would look incomplete rather than inconsistent, in the sense that
it is always possible to add support for changing the default for other options
later, as this is not a case of already having several similar features that
work differently. Your objection is quite strange in this regard. I don't
think we need to draw the line anywhere now. I like your suggestion about
covering other options. Typically, for my use cases, I would enable by default
Re: noatime on ufs2
Chris wrote in <9155214edb61b1bc3bad3bc96f96e...@bsdforge.com>: ... |I haven't seen anything in this thread that wouldn't be better placed in |tuning(7) |or tunefs(8). | |* Silicon disks fail without warning | tapes did as well. Unless you're working with punch cards please \ | implement |an | effective backup strategy -- snapshot(8) |* writing to my disk takes a long time | see tuning(7) or tunefs(8) |* atime doesn't work like "realtime" does on Linux | use Linux instead or add the ability to also use realtime 'Seems to me from a "git grep" that ZFS supports relatime. The number of atime matches for ufs is not that horrifying either. Sure the daily disc crawler touches anything, as was said, so relatime does not help once. For that the crawlers (locate, whatis, whatever) would need to use O_NOATIME, but FreeBSD says /* XXX LINUX_O_NOATIME: unable to be easily implemented. */, so that sucks. Maybe then noatime is the better way out. Having said that, i have never tried it, whether nullfs overmount for the crawlers would get over that. Would be a good thing i'd say, for jailed servers or what. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: noatime on ufs2
On 2024-01-09 00:47, Olivier Certner wrote: Why not make noatime the default across the whole system? Outside of mbox why is recording access time actually useful? Exactly. I've never found any compelling reason in most uses to enable "atime", except perhaps local mail but as addressed in other answers it is a relic of the past mostly irrelevant today. And its drawbacks are well known and can be serious. The auditing use is not what I consider "normal" in the sense I suspect it concerns a small minority of users (maybe even tiny). Plus, serious auditing requires keeping a log (generally immutable) of accesses, i.e., more than a single time and, as pointed out in another answer, at least the ID of the user performing the access. Updating the access time field on files/directories doesn't address both. What "relatime" only gives you is a guarantee that you know that some file has been accessed at some point after its last modification (or creation), and that the access time is correct if precision is only a day. It also generally lowers I/O obviously, but not in some scenarios (file creation and subsequent read). So, to me, at this point, it still sounds more than a gimmick than something really useful. If someone has a precise use case for it and motivation, than of course please go ahead. In the short term, I'd vote for turning "atime" off by default. Thanks and regards. Honestly! Why do we have to upend decades of usage and understanding? Just because it's old doesn't mean it's wrong. Several weeks of replies confirm my initial belief -- atime as it is currently implemented, is as it should be. Administrators and users have spent years to decades finessing their systems and policies based on the way the OS works. In fact administrators and users *pick* their OS based on the way it works. In the case of atime; decades of scripting/policy and utilities have been created based upon the it's expected behavior on any given OS. I haven't seen anything in this thread that wouldn't be better placed in tuning(7) or tunefs(8). * Silicon disks fail without warning tapes did as well. Unless you're working with punch cards please implement an effective backup strategy -- snapshot(8) * writing to my disk takes a long time see tuning(7) or tunefs(8) * atime doesn't work like "realtime" does on Linux use Linux instead or add the ability to also use realtime Security and forensics are good reasons to keep atime unchanged. Any discussion regarding changes to it's current behavior seems folly or bikeshedding. Apologies for the "attitude". --Chris
Re: noatime on ufs2
On Jan 15, 2024, at 01:27, Tomoaki AOKI wrote: > On Sun, 14 Jan 2024 16:13:06 -0800 > Mark Millard wrote: > >> On Jan 14, 2024, at 14:27, Tomoaki AOKI wrote: >> >>> On Sun, 14 Jan 2024 10:53:34 -0800 >>> Mark Millard wrote: >>> On Jan 14, 2024, at 08:39, Olivier Certner wrote: > 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. I seriously care about having a lack of access times. Yet, I've no objection to needing to be explicit about it in commands and subroutine interfaces, given the long standing interfaces (defaults). It would be different if I could not achieve the lack of access times. That defaults do not block having the desired settings makes the change optional, not technically required. The defaults are, thus, primarily social/political aspects of interfaces, not technical requirements to make things work. Given that, I explicitly claim that avoiding POLA at this late stage is my preference for the priority of competing considerations. I make no claim of knowing the majority view of the tradeoffs. I would claim that, if the majority is not by just some marginal amount, contradicting that majority view for this would not be appropriate. (Again: the social/political aspects.) And, hopefully, this is my last contribution to this particular bike shed. === Mark Millard marklmi at yahoo.com >>> >>> I would prefer violating POLA here, with, for example, forcing admins >>> to choose explicitly with installer menu >> >> I've not reported any objection to bsdinstall having explicit >> choices required in its menus. Nor to changing how, say, >> official snapshots are generated (so long as well notified >> and documented). If my wording was unclear on that, I'm sorry. >> >> My focus was on things like mount command notation and >> /etc/fstab notation (that tracks mount defaults) or subroutine >> interface equivalents of such things and changing their >> behavior without requiring changing the notation already in >> place in various files. >> >> (I've tried to word the above without making new points, >> avoiding contributing more to the bike shed material.) >> >>> Choose whether you need to retain last file access time or not: >>> 1: Don't keep(current default) >>> 2: Keep last one (default before 15.0) >>> >>> by hand, or via installer configuration or additional scripts. >>> Of course, existing installations should not be affected. >>> >> >> >> === >> Mark Millard >> marklmi at yahoo.com > > So you mean changing behaviour of mount[_*] to default to noatime, in > conjunction with configuration in /etc/fstab to default to noatime, > right? > So if changes are done as such, if anyone want atime active, add > "-o atime" in mount[_*] command and/or "[,]atime" in /etc/fstab? In my stated view, if bsdinstall is modified for UFS it should generate /etc/fstab files with explicit "noatime" notation when the user selects to not have atime. If they select to have atime in use instead, two ways would work: be explicit in /etc/fstab with an "atime" or leave it implicit for what I've stated as my view. As far as I'm concerned, the generated /etc/fstab could always be explicit, avoiding any dependency on the default for lack of having explicit notation. But, I'll note that the existing "man mount" only mentions the "noatime" notation, not the possibility of an explicit "atime". The same goes for "man fstab". No matter what, the documentation could be explicit about both notations, noting which ends up being the default for when the user's notation is not explicit. I've indicated that my preference for the lack of explicit notation would be to continue to have it mean "atime" implicitly. But tools like bsdinstall need not output files that depend on that at all: the /etc/fstab files could always be generated with explicit notation. Hopefully, the above is clear and I can avoid having to yet again describe my view. Again I've tried to word the above without making new points, avoiding contributing more to the bike shed material. === Mark Millard marklmi at yahoo.com
Re: noatime on ufs2
On Sun, 14 Jan 2024 16:13:06 -0800 Mark Millard wrote: > On Jan 14, 2024, at 14:27, Tomoaki AOKI wrote: > > > On Sun, 14 Jan 2024 10:53:34 -0800 > > Mark Millard wrote: > > > >> On Jan 14, 2024, at 08:39, Olivier Certner wrote: > >> > >>> 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. > >> > >> I seriously care about having a lack of access times. Yet, I've no > >> objection to needing to be explicit about it in commands and > >> subroutine interfaces, given the long standing interfaces (defaults). > >> It would be different if I could not achieve the lack of access > >> times. That defaults do not block having the desired settings makes > >> the change optional, not technically required. The defaults are, > >> thus, primarily social/political aspects of interfaces, not > >> technical requirements to make things work. > >> > >> Given that, I explicitly claim that avoiding POLA at this late stage > >> is my preference for the priority of competing considerations. I > >> make no claim of knowing the majority view of the tradeoffs. I would > >> claim that, if the majority is not by just some marginal amount, > >> contradicting that majority view for this would not be appropriate. > >> (Again: the social/political aspects.) > >> > >> And, hopefully, this is my last contribution to this particular > >> bike shed. > >> > >> === > >> Mark Millard > >> marklmi at yahoo.com > > > > I would prefer violating POLA here, with, for example, forcing admins > > to choose explicitly with installer menu > > I've not reported any objection to bsdinstall having explicit > choices required in its menus. Nor to changing how, say, > official snapshots are generated (so long as well notified > and documented). If my wording was unclear on that, I'm sorry. > > My focus was on things like mount command notation and > /etc/fstab notation (that tracks mount defaults) or subroutine > interface equivalents of such things and changing their > behavior without requiring changing the notation already in > place in various files. > > (I've tried to word the above without making new points, > avoiding contributing more to the bike shed material.) > > > Choose whether you need to retain last file access time or not: > >1: Don't keep(current default) > >2: Keep last one (default before 15.0) > > > > by hand, or via installer configuration or additional scripts. > > Of course, existing installations should not be affected. > > > > > === > Mark Millard > marklmi at yahoo.com So you mean changing behaviour of mount[_*] to default to noatime, in conjunction with configuration in /etc/fstab to default to noatime, right? So if changes are done as such, if anyone want atime active, add "-o atime" in mount[_*] command and/or "[,]atime" in /etc/fstab? -- Tomoaki AOKI
Re: noatime on ufs2
Am 2024-01-15 00:08, schrieb Olivier Certner: Hi Warner, The consensus was we'd fix it in the installer. Isn't speaking about a "consensus", at least as a general response to the idea of making 'noatime' the default, a little premature? I have more to say on this topic (see below). Also, I would not dismiss Lyndon's last mail too quickly, and in particular the last paragraph. I'm as interested as he is about possible answers for it. We can't change ZFS easily, and discovery of the problem, should your assertion be wrong, for UFS means metadata loss that can't be recovered. Why ZFS would need changing? If you're referring to an earlier objection from Mark Millard, I don't think it stands, please see my response to him. Else, I don't know what you're referring to. ZFS by default has atime=on. It is our installer which sets atime=off in the ZFS properties. I was understanding Warners comment about changing ZFS in the sense of changing the ZFS code to have a default of atime=off. I agree with Warner that we should not do that. And in my opinion we should keep the other FS which support atime/noatime consistent (those which don't support atime/noatime due to technial limitations don't count in my opinion). By pushing to the installer, most installations get most of benefits. And people with special needs see the issue and can make an informed choice. I agree for those who use the installer. But I'm not sure which proportion of users they represent, and especially for those who care about disabling access times. As for me, I don't think I have used the installer in the past 10 years (to be safe). Is this such an atypical behavior? I haven't used an installer myself since longer (either I was creating a new system by attaching a disk and prepping it from an existing system, or by creating an image and transferring it to the target over the network). But I would say this is atypical behavior by people which know exactly what they are doing, not what a normal consumer would do. Such experts know exactly what they want to do with atime and handle it as needed. Additionally, the installer doesn't cover other use cases: - Mounting filesystems by hand on USB keys or other removal medias (which are not in '/etc/fstab'). This causes users to have to remember to add 'noatime' on the command-line. Those which care about that and know where this makes a difference, have it in their finger-memory. - Using auto-mounters. They have to be configured to use 'noatime'. If our automounter is not able to handle that, it is a bug / missing feature we can change. Personally I would have no objection to changing the automounter config to mount with noatime (if specifying noatime for a FS which don't support atime/noatime doesn't create failures). - Desktop environments shipping a mount helper. Again, they have to be configured, if at all possible. If they are not able to handle that, it is a bug. Typical media in desktop use-cases doesn't really need this. If you handle media which really _needs_ noatime in such a case, you may want to reconsider your way of operating. So limiting action to the installer, while certainly a sensible and pragmatic step, still seems to miss a lot. Nobody told to only limit this action to the installer. The pragmatic part here is to ask if it really matters for those use cases. For mounting by hand I disagree that it matters. For our automounter we should do something (at least making sure it is able to handle it, and if we don't want to swtich the default at least have a commented out entry in the config with a suitable comment). For the desktop helpers it is not our responsability, but interested people surely can file a bug report upstream. Though in all honesty, I've never been able to measure a speed difference. Nor have I worn out a ssd due to the tiny increase in write amp. Old (<100MB) SD and CF cards included. This includes my armv7 based dns server that I ran for a decade on a 256MB SD card with no special settings and full read/write and lots of logging. So the harm is minimal typically. I'm sure there are cases that it matters more than my experience. And it is good practice to enable noatime. Just that failure to do so typically has only a marginal effect. It seemed to make a difference on slow USB keys (well, not just evenly slow, but which could exhibit strange pauses while writing), but I didn't gather enough hard data to call that "scientific". I sometimes manage to saturate M2 SSD I/O bandwidth but then I always use 'noatime', so not sure how much a difference it makes. The "updatedb" scenario that runs 'find' causes access time updates for all directories, causing spikes in the number of writes which may affect the response time during the process. That said, it is only run once a week by default. I would say that most of the value of having 'noatime' the default is in
Re: noatime on ufs2
Am Sun, 14 Jan 2024 19:14:16 +0100 schrieb "Patrick M. Hausen" : > That number at first looks like a serious load on the write endurance > of your SSD. Then, doing the math it turns out it's absolutely > ridiculous. > > 100 kB/s sums up to 8,640 GB/day (in decimal units). Even the small > SSDs typically used for embedded devices like firewalls (32 or 64 G > capacity) have a write endurance in the order of 100 or 200 TBW. > > That's more than 10.000 days or roughly 30 years ... This highly depends on how your written data are distributed on the disk. I have seen cases of write amplification by orders of magnitude, e.g., when adding few bytes on many (several 10k) different files. cu Gerrit smime.p7s Description: S/MIME cryptographic signature
Re: noatime on ufs2
On Jan 14, 2024, at 15:15, Olivier Certner wrote: > Hi Mark, > >> I seriously care about having a lack of access times. > > Then, I think elaborating on your use cases would be valuable to the > discussion, if by chance you want to and can share about them. I'm confused: I go to the trouble to produce the same end result as your suggested change of defaults would produce, ending up with no recording of access times. Nothing about that of itself implies that I'd want the defaults for mount notation or /etc/fstab notation or the like changed --or that I'd want them unchanged. To narrow of a context for such a judgment about defaults. In case the potential confusion is involved, I'll quote another reply that I just made relative to more potential use of notime: QUOTE I've not reported any objection to bsdinstall having explicit choices required in its menus. Nor to changing how, say, official snapshots are generated (so long as well notified and documented). If my wording was unclear on that, I'm sorry. My focus was on things like mount command notation and /etc/fstab notation (that tracks mount defaults) or subroutine interface equivalents of such things and changing their behavior without requiring changing the notation already in place in various files. (I've tried to word the above without making new points, avoiding contributing more to the bike shed material.) END QUOTE === Mark Millard marklmi at yahoo.com
Re: noatime on ufs2
On Jan 14, 2024, at 14:27, Tomoaki AOKI wrote: > On Sun, 14 Jan 2024 10:53:34 -0800 > Mark Millard wrote: > >> On Jan 14, 2024, at 08:39, Olivier Certner wrote: >> >>> 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. >> >> I seriously care about having a lack of access times. Yet, I've no >> objection to needing to be explicit about it in commands and >> subroutine interfaces, given the long standing interfaces (defaults). >> It would be different if I could not achieve the lack of access >> times. That defaults do not block having the desired settings makes >> the change optional, not technically required. The defaults are, >> thus, primarily social/political aspects of interfaces, not >> technical requirements to make things work. >> >> Given that, I explicitly claim that avoiding POLA at this late stage >> is my preference for the priority of competing considerations. I >> make no claim of knowing the majority view of the tradeoffs. I would >> claim that, if the majority is not by just some marginal amount, >> contradicting that majority view for this would not be appropriate. >> (Again: the social/political aspects.) >> >> And, hopefully, this is my last contribution to this particular >> bike shed. >> >> === >> Mark Millard >> marklmi at yahoo.com > > I would prefer violating POLA here, with, for example, forcing admins > to choose explicitly with installer menu I've not reported any objection to bsdinstall having explicit choices required in its menus. Nor to changing how, say, official snapshots are generated (so long as well notified and documented). If my wording was unclear on that, I'm sorry. My focus was on things like mount command notation and /etc/fstab notation (that tracks mount defaults) or subroutine interface equivalents of such things and changing their behavior without requiring changing the notation already in place in various files. (I've tried to word the above without making new points, avoiding contributing more to the bike shed material.) > Choose whether you need to retain last file access time or not: >1: Don't keep(current default) >2: Keep last one (default before 15.0) > > by hand, or via installer configuration or additional scripts. > Of course, existing installations should not be affected. > === Mark Millard marklmi at yahoo.com
Re: noatime on ufs2
Hi Mark, > I seriously care about having a lack of access times. Then, I think elaborating on your use cases would be valuable to the discussion, if by chance you want to and can share about them. Thanks and regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi Warner,
> The consensus was we'd fix it in the installer.
Isn't speaking about a "consensus", at least as a general response to the idea
of making 'noatime' the default, a little premature? I have more to say on
this topic (see below). Also, I would not dismiss Lyndon's last mail too
quickly, and in particular the last paragraph. I'm as interested as he is
about possible answers for it.
> We can't change ZFS easily, and discovery of the problem, should your
> assertion be wrong, for UFS means metadata loss that can't be recovered.
Why ZFS would need changing? If you're referring to an earlier objection from
Mark Millard, I don't think it stands, please see my response to him. Else, I
don't know what you're referring to.
If I'm understanding you correctly, strictly speaking, it's true there would be
metadata loss (access times cease to be updated). As a reminder, this only
concerns people caring about access times, and who wouldn't notice the change
in default despite it being publicized, so a small minority as we can forecast
for now. Furthermore, for the scenarios already presented, recovering exact
lost metadata is not necessary, their absence "only" complicates matters
temporarily. To know which files/packages are used, you install them and then
run your system for enough time (more or less arbitrary) before checking the
access times. Unless you're monitoring a very specific access pattern that
would be hard to reproduce, you can just repeat the experience when access
times are re-enabled. For backups, access times could be used to know which
files really matter, but then you have the option to backup them all instead
until you get the metadata for the next backup. All that assuming, as said in
an earlier mail, that nothing has messed up with the access times in the
meantime, which would ruin the feasibility of such scenarios in the first place.
> By pushing to the installer, most installations get most of benefits. And
> people with special needs see the issue and can make an informed choice.
I agree for those who use the installer. But I'm not sure which proportion of
users they represent, and especially for those who care about disabling access
times. As for me, I don't think I have used the installer in the past 10 years
(to be safe). Is this such an atypical behavior?
Additionally, the installer doesn't cover other use cases:
- Mounting filesystems by hand on USB keys or other removal medias (which are
not in '/etc/fstab'). This causes users to have to remember to add 'noatime'
on the command-line.
- Using auto-mounters. They have to be configured to use 'noatime'.
- Desktop environments shipping a mount helper. Again, they have to be
configured, if at all possible.
So limiting action to the installer, while certainly a sensible and pragmatic
step, still seems to miss a lot.
> Though in all honesty, I've never been able to measure a speed difference.
> Nor have I worn out a ssd due to the tiny increase in write amp. Old
> (<100MB) SD and CF cards included. This includes my armv7 based dns server
> that I ran for a decade on a 256MB SD card with no special settings and
> full read/write and lots of logging. So the harm is minimal typically. I'm
> sure there are cases that it matters more than my experience. And it is
> good practice to enable noatime. Just that failure to do so typically has
> only a marginal effect.
It seemed to make a difference on slow USB keys (well, not just evenly slow,
but which could exhibit strange pauses while writing), but I didn't gather
enough hard data to call that "scientific". I sometimes manage to saturate M2
SSD I/O bandwidth but then I always use 'noatime', so not sure how much a
difference it makes. The "updatedb" scenario that runs 'find' causes access
time updates for all directories, causing spikes in the number of writes which
may affect the response time during the process. That said, it is only run
once a week by default.
I would say that most of the value of having 'noatime' the default is in less
tweaking by most people, and one less thing to worry about (for them).
I proposed in another mail having a sysctl which indicates the default
('noatime' or 'atime') for all filesystems. This default would be used at
mount time if neither 'atime' nor 'noatime' is explicitly specified. That way,
people wanting 'noatime' by default everywhere could just set it to that. It
may also convince reticent people to have the default (i.e., this sysctl's
default value) changed to 'noatime', by providing a very simple way to revert
to the old behavior.
Thanks and regards.
--
Olivier Certner
signature.asc
Description: This is a digitally signed message part.
Re: noatime on ufs2
Olivier Certner wrote: > I've mentioned your answer in another response to Lyndon Nerenberg when > developing a more general argument that 'atime' is generally flawed for these > kinds of use cases (finding the last use, finding files to backup, etc.). > It's true that the ability to deactivate 'atime''s implicit updates > per-process would cater to more use cases, and it's an interesting idea. > Essentially, though, you can't guarantee that some applications, or simply > administrators typing commands at the shell, are not going to throw away your > precious access times, so can't rely (in a strong sense) on them. Thanks for the heads-up - I've only now had a chance to catch up with the thread. You are of course right - atime can be affected by so many different things that it can't be relied upon. I just thought a per-process method would be a good compromise to avoid blanket atime changes across the system - both for atime usefulness, and I/O, but as you say, as it's unreliable to rely on anyway, this solution may be making things worse by giving a false sense of reliability. And to further bolster your point, whilst I have wished for more granuality with respect to controlling atime updates, for years I've run everything with noatime.. Even when I thought it was nice to keep atime relatively accurate, I soon realised that I simply never used it anyway! > Sure for backups and snapshots. I agree you'd better have backup perimeters > coinciding with file systems partitions and use snapshots to get the > smoothest possible experience. But snapshots alone do not guarantee the > "correctness" of a backup (the ability to restart smoothly from it). Yeah, it's more like a snapshot at the time of a power failure, but of course, it's better than running on a live filesystem because a file may be missed completely if moved whilst the backup is running. But short of shutting everything down prior to taking the snapshot (I remember at last job some very old machines without snapshotting or decent db journalling capabilities being taken down for hours every night, so that the whole backup ran in a minimal boot environment!), I don't know of a cleaner solution... (though I'm sure some exist.. after all, live migrations between hosts are a thing these days.. I guess I need to do some homework on the matter! :-) ) Thanks again, Jamie
Re: noatime on ufs2
On Sun, 14 Jan 2024 10:53:34 -0800 Mark Millard wrote: > On Jan 14, 2024, at 08:39, Olivier Certner wrote: > > > 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. > > I seriously care about having a lack of access times. Yet, I've no > objection to needing to be explicit about it in commands and > subroutine interfaces, given the long standing interfaces (defaults). > It would be different if I could not achieve the lack of access > times. That defaults do not block having the desired settings makes > the change optional, not technically required. The defaults are, > thus, primarily social/political aspects of interfaces, not > technical requirements to make things work. > > Given that, I explicitly claim that avoiding POLA at this late stage > is my preference for the priority of competing considerations. I > make no claim of knowing the majority view of the tradeoffs. I would > claim that, if the majority is not by just some marginal amount, > contradicting that majority view for this would not be appropriate. > (Again: the social/political aspects.) > > And, hopefully, this is my last contribution to this particular > bike shed. > > === > Mark Millard > marklmi at yahoo.com I would prefer violating POLA here, with, for example, forcing admins to choose explicitly with installer menu Choose whether you need to retain last file access time or not: 1: Don't keep(current default) 2: Keep last one (default before 15.0) by hand, or via installer configuration or additional scripts. Of course, existing installations should not be affected. -- Tomoaki AOKI
Re: noatime on ufs2
On Jan 14, 2024, at 08:39, Olivier Certner wrote: > 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. I seriously care about having a lack of access times. Yet, I've no objection to needing to be explicit about it in commands and subroutine interfaces, given the long standing interfaces (defaults). It would be different if I could not achieve the lack of access times. That defaults do not block having the desired settings makes the change optional, not technically required. The defaults are, thus, primarily social/political aspects of interfaces, not technical requirements to make things work. Given that, I explicitly claim that avoiding POLA at this late stage is my preference for the priority of competing considerations. I make no claim of knowing the majority view of the tradeoffs. I would claim that, if the majority is not by just some marginal amount, contradicting that majority view for this would not be appropriate. (Again: the social/political aspects.) And, hopefully, this is my last contribution to this particular bike shed. === Mark Millard marklmi at yahoo.com
Re: noatime on ufs2
Hi folks, that's a really interesting polite and constructive discussion going on here, and a trip down history lane to boot :-) I just want to add one thing to Warner's last argument: > Am 14.01.2024 um 18:58 schrieb Warner Losh : > Though in all honesty, I've never been able to measure a speed difference. > Nor have I worn out a ssd due to the tiny increase in write amp. Recently on the OPNsense forum somehow an increasing number of users started to post worried questions regarding a constant write load on the system disk/SSD in the order of 100 kB/s or some small multitude thereof. Definitely smaller than 1MB/s. That number at first looks like a serious load on the write endurance of your SSD. Then, doing the math it turns out it's absolutely ridiculous. 100 kB/s sums up to 8,640 GB/day (in decimal units). Even the small SSDs typically used for embedded devices like firewalls (32 or 64 G capacity) have a write endurance in the order of 100 or 200 TBW. That's more than 10.000 days or roughly 30 years ... That's why I like following this discussion and every improvement is in then end an improvement, but I consider it mostly a micro optimisation. Kind regards, Patrick P.S. I don't use atime anywhere I knew.
Re: noatime on ufs2
Warner Losh writes: > > I'm really interested in hearing from people who actively use > > atime on a regular basis for non-trivial purposes. What are > > the modern use cases for atime? > The consensus was we'd fix it in the installer. Sure, but my question still stands. I'm genuinely curious to know how (or if) people still use atime. --lyndon
Re: noatime on ufs2
On Sun, Jan 14, 2024, 10:24 AM Lyndon Nerenberg (VE7TFX/VE6BBM) < lyn...@orthanc.ca> wrote: > > > I do not have a strong opinion w.r.t. atime, but I do believe that > > > changing the default would be a POLA violation. > > I'm not prepared to just accept that at face value. > > I can't think of a single instance in at least the last three decades > where I have actually used or needed atime for *anything*. And > over that time period I have been responsible for running hundreds > of UNIX servers. > > I'm really interested in hearing from people who actively use > atime on a regular basis for non-trivial purposes. What are > the modern use cases for atime? > The consensus was we'd fix it in the installer. We can't change ZFS easily, and discovery of the problem, should your assertion be wrong, for UFS means metadata loss that can't be recovered. By pushing to the installer, most installations get most of benefits. And people with special needs see the issue and can make an informed choice. Though in all honesty, I've never been able to measure a speed difference. Nor have I worn out a ssd due to the tiny increase in write amp. Old (<100MB) SD and CF cards included. This includes my armv7 based dns server that I ran for a decade on a 256MB SD card with no special settings and full read/write and lots of logging. So the harm is minimal typically. I'm sure there are cases that it matters more than my experience. And it is good practice to enable noatime. Just that failure to do so typically has only a marginal effect. Warner --lyndon > >
Re: noatime on ufs2
> > I do not have a strong opinion w.r.t. atime, but I do believe that > > changing the default would be a POLA violation. I'm not prepared to just accept that at face value. I can't think of a single instance in at least the last three decades where I have actually used or needed atime for *anything*. And over that time period I have been responsible for running hundreds of UNIX servers. I'm really interested in hearing from people who actively use atime on a regular basis for non-trivial purposes. What are the modern use cases for atime? --lyndon
Re: noatime on ufs2
Hi Mike, > I like the idea of an option in bsdinstall, but I don't think it is necessary > to check the storage type. It could simply default to noatime. > > I think we should automatically use noatime on SD card images (where > bsdinstall > doesn't get used). One of the perhaps unappreciated point and advantage of having 'noatime' as the default is to avoid the complexity of both special casing based on media type and having to configure the different applications that can mount partitions (depending on your uses, there isn't only '/etc/fstab'). Thanks and regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi Rodney, > ... Very well said Mark ... I don't share that enthusiasm. Please see my direct response to Mark. > Please folks stop tweaking defaults, especially long standing ones, > if you feel the need for noatime, set it, by all means, I have been > for 30 years If you're implying that I have been proposing to make 'noatime' the default thoughtlessly, because I jumped in following a question by rob...@rrbrussell.com, then you couldn't be further from the truth (please see my other mails). If, despite that, this discussion bothers you, and for reasons that seem to be unrelated with the topic, what can I say? Nothing forces you to participate. Thanks at least for admitting that you're using 'noatime', as well as most of the other backers of the status quo in this discussion. Perhaps that should tell you something. Regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
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
Re: noatime on ufs2
Hi Rick,
> I do not have a strong opinion w.r.t. atime, but I do believe that
> changing the default would be a POLA violation.
While I value POLA very highly, at the same time I do not consider it a
sacrosanct principle that must be followed in every possible circumstances.
There are many different ways and levels of being amazed, and varying
counterparties to gain in exchange, so there cannot be any absolute
interpretation of it. Moreover, the stricter you are in general, the more you
are pushing the project towards fossilization. It's true that there are lots
of mechanisms to allow both backwards compatibility and evolution in lots of
different cases, but they come at a cost which is increased complexity, amount
of code and configuration, which has to be taken into account as well.
Here, I do not think activating 'noatime' by default would be a significant
violation of POLA. On the contrary, I think that almost nobody will notice it,
so there barely will be any amazement. Why? First case: The user/admin
doesn't care, so is using the default. Most of them will never ever use
'atime' for any purposes. Some will try to use if a few times, discovering on
occasion that they cannot because something messed up with them (if 'atime' is
the default) or because they are not maintainted (if 'noatime' is the default).
Second case: The user/admin cares, and wants/needs to avoid the extra I/O, so
decides to uses 'noatime'. These people won't even notice a change, since they
are using 'noatime' already. Third case: The user/admin cares, and wants the
access times to be updated. If he's using an explicit 'atime', it's the same
as the previous case. If, as is likely, he's not explicit, he will notice the
change as some of his scenarios will start to fail, with more or less bad
consequences. I don't think this is really different than lots of changes the
project has gone through. The very important thing, but the only one, we would
have to do is publicizing this part correctly ("if you're relying on access
times, be sure to change your mount options, and possibly configure your
auto-mounting applications and/or other mount helpers so that 'atime' is
explicitly enabled.").
I address other POLA-related points raised by Mark Millard in a direct response
to his mail.
> Please look at this email thread, where the opinion w.r.t. atime
> seemed quite different:
> freebsd-hackers@ Oct. 5, 2023
> Subject: copy_file_range() doesn't update the atime of an empty file
>
> I'd put a url here, but gmail always puts the subject line in here when
> I copy/paste the url?
No problem, I found it online.
I only re-subscribed to hackers@ a few months ago after discovering I had been
seemingly unsubscribed for a while without knowing it.
> Basically I did not think that updating the infd's atime when
> copy_file_range()
> did not actually copy any data, but the collective disagreed, so I patched
> the NFSv4 client. (I do not know if markj@'s patch did get committed).
> They also collectively thought that Linux did a poor job w.r.t. atime.
I completely support the view that, if a copy realized through VOP_READ()
updates the access time, so should a copy realized through copy_file_range().
That is arguably also an application of POLA, but in fact here is much more: A
matter of correctness.
However I fail to see how that thread, as a whole, has any connection with the
discussion we are having. Could you please elaborate?
Thanks and regards.
--
Olivier Certner
signature.asc
Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi Jamie, > I've often wished there was the ability to set a process to "noatime" - where > all accesses to the filesytem by the process and its children don't alter > atime. It would be handy for those cases you describe above, such as backups > and locate, but these days, where it matters, and is suitable, I instead > create a filesystem snapshot, and run the process on that instead. (which is > how "live" backups should be done anyway!) I've mentioned your answer in another response to Lyndon Nerenberg when developing a more general argument that 'atime' is generally flawed for these kinds of use cases (finding the last use, finding files to backup, etc.). It's true that the ability to deactivate 'atime''s implicit updates per-process would cater to more use cases, and it's an interesting idea. Essentially, though, you can't guarantee that some applications, or simply administrators typing commands at the shell, are not going to throw away your precious access times, so can't rely (in a strong sense) on them. Sure for backups and snapshots. I agree you'd better have backup perimeters coinciding with file systems partitions and use snapshots to get the smoothest possible experience. But snapshots alone do not guarantee the "correctness" of a backup (the ability to restart smoothly from it). Cheers. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi Lyndon, > > I've never found any compelling reason in most uses to enable "atime", > > except perhaps local mail (snip). > When UNIX ran on PDP-11s and disk pack sizes were measured in the > tens of megabytes, atime was very helpful in determining which files > were likely candidates for archiving to tape when the disk was > getting full. I appreciate this kind of historical information. According to Wikipedia, most of the PDP-11's lifespan after my birth date overlaps only with my childhood and teenage years, and I had never the chance (or curse, I don't know) to get around to one (actually, I only learned about its existence years later, much after after its phasing out). This purpose, i.e., "determine which files to archive", was achieved by relying on 'atime' I guess by selecting those whose access times were the oldest (perhaps combined with other criteria). The mean employed here is exactly the same as for the use cases reported by Warner: Being able to know which executables / libraries / packages are effectively used. So this approach has exactly the same problems. As I explained in a response to Warner, it is currently almost unpracticable on FreeBSD, because some periodic processes mess up with the access times (for more details, please read it). But more deeply, as sketched in that response, the problem is "general": Relying on access times is bound to be fragile, simply because they are updated implicitly, without the applications asking for it at all and for most neither being aware. The use cases presented for 'atime' so far all assume that the access times will be updated only on some action that is relevant to their scenarios. But you can't prevent other actions not in your scenario from updating these access times, and it can be very hard in practice to predict which can occur on a given install (depending, e.g., on how many software packages you've installed, their provenance, etc.). In some answer, Jamie Landeg-Jones suggested to have a per-process flag to control the implicit access times update, which is a workaround that is probably enough in some use cases, but not for all (see my response there). At the same time, I'd like people to realize that it is still no more than a workaround, or a "clever" way to solve one's problem in particular circumstances, but is not a generally reliable solution. What I'm evoking here concerns more the "usefulness of 'atime'" discussion than the "default should be 'noatime'", but has non-negligible bearing on the latter. > And in the Usenet days it was common to mount > /var/spool/news noatime, which eliminated a *lot* of meta-info > write traffic. A logical, completely predictable move. > These days, other than /var/mail, I can't think of a compelling use > for it. I've been running my Plan 9 systems with atime disabled > ever since fossil arrived (decades) without any impact. I agree. That's exactly the reason why I wanted to seize the occasion of rob...@rrbrussell.com's question to present my take, because I had been wondering about that a few times in the last 5 to 10 years and also never encountered a compelling reason for why it should be the default. And I insist: The initial discussion, and my main focus, is about 'noatime' becoming the default. The discussions about the usefulness of 'relatime' and 'atime' are very interesting, and I'm even participating to those, but to me are secondary in the end. The usefulness of 'atime' is of course in part connected to the default to use, but they are still very different questions. For example, concerning the former, the frequency of needs (how many uses?) is not very important, whereas it matters a lot when it comes to which default to choose. > I don't see any issue with making noatime the default. For those > that must have it, /var/mail can be carved out as a distinct > filesystem and mounted appropriately. The summary of the technical side of this discussion so far is that there most likely won't be any issue at all for the vast majority of users if 'noatime' becomes the default. We'll see if more reports for other scenarios are to come (or if we can find or guess some ourselves; irrespective of whether they validate or not the current evaluation). And, as reported by others, even /var/mail should not need it in most uses given that all prominent MUAs have long departed from using the access time comparison alone. (I won't pronounce myself on this since I'm not personally using them, but I'm not seeing any reason not to trust the reports. If some people have contradictory facts, I hope that they will present them.) Thanks and regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
On Fri, Jan 12, 2024 at 6:15 PM Dag-Erling Smørgrav wrote: > Tomek CEDRO writes: > > I am reading this interesting discussion and please verify my general > > understanding: > > 1. There is a request for change in core OS / FS mechanism of file > > access time (atime) because of problem with mailing application? > > The atime mechanism is considered harmful by many because every file > access results in a write which (even if coalesced) not only impacts > performance but also increases wear on SSDs. Many people turn it off. > Even the FreeBSD installer turns it off when installing to ZFS, except > on `/var/mail` which is a separate filesystem precisely so that it can > have atime enabled independently of the rest of the system. There is a > proposal to turn it off by default.(..) Okay, the discussion got some (and enough) traction, and its about changing defaults only, not the underlying kernel or filesystem code to change the atime behavior, so this can be done as an option that user will see and can change easily in the installer.. and still good old atime can be used where necessary whoever needs it :-) > > 2. Linux change of approach to atime that keeps its value only around > > last 24h so we should also change it in FreeBSD? > > > > 3. "realtime" is the alternative solution to keep atime intact? > > The Linux approach is an alternative mechanism dubbed “relatime” > (relative access time) which instead of updating the access time on > every access, does so only if the previous atime is either older than > the current mtime or more than 24 h ago. rel-atime roger! :-) :-) Thanks DES :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: noatime on ufs2
Tomek CEDRO writes: > I am reading this interesting discussion and please verify my general > understanding: > > 1. There is a request for change in core OS / FS mechanism of file > access time (atime) because of problem with mailing application? The atime mechanism is considered harmful by many because every file access results in a write which (even if coalesced) not only impacts performance but also increases wear on SSDs. Many people turn it off. Even the FreeBSD installer turns it off when installing to ZFS, except on `/var/mail` which is a separate filesystem precisely so that it can have atime enabled independently of the rest of the system. There is a proposal to turn it off by default. > 2. Linux change of approach to atime that keeps its value only around > last 24h so we should also change it in FreeBSD? > > 3. "realtime" is the alternative solution to keep atime intact? The Linux approach is an alternative mechanism dubbed “relatime” (relative access time) which instead of updating the access time on every access, does so only if the previous atime is either older than the current mtime or more than 24 h ago. > Why change well known standardized and widely used mechanism that is > here for decades? Because it's harmful and most people don't use it. > If there is a problem with an application why change core OS/FS with > all possible negative consequences and not fix the application? There is not “a problem with an application”. No application actually requires atime to function properly because developers knows that atime is a) not universally supported and b) often disabled even when supported. There is however a problem with disk performance and lifetime being degraded. > Wouldn't that break POSIX / backward compatiblity? No. Many people, and the FreeBSD installer, already turn it off. The relatime mechanism would restore atime functionality while causing much less harm, in theory. I'm not sure it would make much difference in practice considering that we have nightly scripts which would trigger atime updates even with relatime. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: noatime on ufs2
Am 2024-01-11 18:15, schrieb Rodney W. Grimes:
Am 2024-01-10 22:49, schrieb Mark Millard:
> I never use atime, always noatime, for UFS. That said, I'd never
> propose
> changing the long standing defaults for commands and calls. I'd avoid:
[good points I fully agree on]
There's one possibility which nobody talked about yet... changing the
default to noatime at install time in fstab / zfs set.
Perhaps you should take a closer look at what bsdinstall does
when it creates a zfs install pool and boot environment, you
might just find that noatime is already set everywhere but
on /var/mail:
/usr/libexec/bsdinstall/zfsboot:: ${ZFSBOOT_POOL_CREATE_OPTIONS:=-O
compress=lz4 -O atime=off}
/usr/libexec/bsdinstall/zfsboot:/var/mail atime=on
While zfs is a part of what I talked about, it is not the complete
picture. bsdinstall covers UFS and ZFS, and we should keep them in sync
in this regard. Ideally with an option the user can modify. Personally I
don't mind if the default setting for this option would be noatime. A
quick serach in the scripts of bsdinstall didn't reveal to me what we
use for UFS. I assume we use atime.
I fully agree to not violate POLA by changing the default to noatime
in
any FS. I always set noatime everywhere on systems I take care about,
no
exceptions (any user visible mail is handled via maildir/IMAP, not
mbox). I haven't made up my mind if it would be a good idea to change
bsdinstall to set noatime (after asking the user about it, and later
maybe offer the possibility to use relatime in case it gets
implemented). I think it is at least worthwile to discuss this
possibility (including what the default setting of bsdinstall should
be
for this option).
Little late... iirc its been that way since day one of zfs support
in bsdinstall.
Which I don't mind, as this is what I use anyway. But the correct way
would be to let the user decide.
Bye,
Alexander.
--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF
signature.asc
Description: OpenPGP digital signature
Re: noatime on ufs2
Rodney W. Grimes wrote on
Date: Thu, 11 Jan 2024 17:15:19 UTC :
> > Am 2024-01-10 22:49, schrieb Mark Millard:
> >
> > > I never use atime, always noatime, for UFS. That said, I'd never
> > > propose
> > > changing the long standing defaults for commands and calls. I'd avoid:
> >
> > [good points I fully agree on]
> >
> > There's one possibility which nobody talked about yet... changing the
> > default to noatime at install time in fstab / zfs set.
>
> Perhaps you should take a closer look at what bsdinstall does
> when it creates a zfs install pool and boot environment, you
> might just find that noatime is already set everywhere but
> on /var/mail:
>
> /usr/libexec/bsdinstall/zfsboot:: ${ZFSBOOT_POOL_CREATE_OPTIONS:=-O
> compress=lz4 -O atime=off}
> /usr/libexec/bsdinstall/zfsboot: /var/mail atime=on
>
> >
> > I fully agree to not violate POLA by changing the default to noatime in
> > any FS. I always set noatime everywhere on systems I take care about, no
> > exceptions (any user visible mail is handled via maildir/IMAP, not
> > mbox). I haven't made up my mind if it would be a good idea to change
> > bsdinstall to set noatime (after asking the user about it, and later
> > maybe offer the possibility to use relatime in case it gets
> > implemented). I think it is at least worthwile to discuss this
> > possibility (including what the default setting of bsdinstall should be
> > for this option).
>
> Little late... iirc its been that way since day one of zfs support
> in bsdinstall.
>
> > --
> > http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> > http://www.FreeBSD.org netch...@freebsd.org : PGP 0x8F31830F9F2772BF
The UFS based snapshots are more of a mix. The one that I just dd'd to
media has:
# more /etc/fstab
# Custom /etc/fstab for FreeBSD embedded images
/dev/ufs/rootfs / ufs rw 1 1
/dev/msdosfs/EFI/boot/efi msdosfs rw,noatime 0 0
tmpfs /tmptmpfs rw,mode=17770 0
/dev/label/growfs_swap noneswapsw 0 0
So the UFS does not have noatime set up for its mount but the msdosfs
does.
===
Mark Millard
marklmi at yahoo.com
Re: noatime on ufs2
On Thu, Jan 11, 2024 at 6:59 AM Mike Karels wrote: > On 11 Jan 2024, at 7:30, Miroslav Lachman wrote: > > > On 11/01/2024 09:54, Tomoaki AOKI wrote: > >> On Thu, 11 Jan 2024 08:36:24 +0100 > >> Alexander Leidinger wrote: > > > > [..] > > > >>> There's one possibility which nobody talked about yet... changing the > >>> default to noatime at install time in fstab / zfs set. > >>> > >>> I fully agree to not violate POLA by changing the default to noatime in > >>> any FS. I always set noatime everywhere on systems I take care about, > no > >>> exceptions (any user visible mail is handled via maildir/IMAP, not > >>> mbox). I haven't made up my mind if it would be a good idea to change > >>> bsdinstall to set noatime (after asking the user about it, and later > >>> maybe offer the possibility to use relatime in case it gets > >>> implemented). I think it is at least worthwile to discuss this > >>> possibility (including what the default setting of bsdinstall should be > >>> for this option). > > > > [..] > > > >> A different aspect of view. > >> Nowadays, storages are quickly moving from HDD, aka spinning rust, to > >> SSD. > >> And SSD has a risk of sudden-death of wearing out. In ancient days, HDD > >> dies not suddenly and at least some cases admins could have time to > >> replace suspicious drives. But SSD dies basically suddenly. > >> > >> IMHO, this could be a valid reason to violate POLA. In limited use > >> cases, atime is useful, at the cost of amplified write accesses. > >> But in most cases, it doesn't have positive functionality nowadays. > >> > >> Anyway, we should have time to discuss whether it should be done or not > >> until upcoming stable/15 branch. stable/14 is already here and it > >> wouldn't be a good thing to MFC. Only *.0-RELEASE should be the point > >> to introduce this, unlike discussion about vi and ee on forums. > > > > The default values change over time as the needs of people, programs and > hardware change. Many values for sysctls changed over time. > > If "noatime" can help people to not trash SSD / SD storage, I can > imagine that bsdinstall will detect the storage type (simple guess can be > made by diskinfo -v) and offer a "noatime" option that the user can > check/uncheck. This option can be pre-selected for flash based storage. > > I don't care defaults for my-self, I can change them, but sane defaults > should be beneficial for new users without much background knowledge. > > > > Kind regards > > Miroslav Lachman > > I like the idea of an option in bsdinstall, but I don't think it is > necessary > to check the storage type. It could simply default to noatime. > > I think we should automatically use noatime on SD card images (where > bsdinstall > doesn't get used). > > Separately, I think a relatime option would be a good compromise, and I > would > probably use it. > I think these are sensible steps. We already do something similar for ZFS. Warner
Re: noatime on ufs2
Olivier Certner wrote: > Both the examples above prompt some straight objections on the current > usefulness of "atime". First, unless you've disabled building the locate > database in cron (enabled by default, on a weekly basis), access times on > directories lose most of their usefulness. Second, if using an IDS, I'm > afraid it's just game over. And even if you think you are not, > '460.pkg-checksum' at least is readily there to much complicate, or even > prevent you from, getting package usage information this way (it is enabled > by default, and on a daily basis). I've often wished there was the ability to set a process to "noatime" - where all accesses to the filesytem by the process and its children don't alter atime. It would be handy for those cases you describe above, such as backups and locate, but these days, where it matters, and is suitable, I instead create a filesystem snapshot, and run the process on that instead. (which is how "live" backups should be done anyway!) Cheers, Jamie
Re: noatime on ufs2
> Am 2024-01-10 22:49, schrieb Mark Millard:
>
> > I never use atime, always noatime, for UFS. That said, I'd never
> > propose
> > changing the long standing defaults for commands and calls. I'd avoid:
>
> [good points I fully agree on]
>
> There's one possibility which nobody talked about yet... changing the
> default to noatime at install time in fstab / zfs set.
Perhaps you should take a closer look at what bsdinstall does
when it creates a zfs install pool and boot environment, you
might just find that noatime is already set everywhere but
on /var/mail:
/usr/libexec/bsdinstall/zfsboot:: ${ZFSBOOT_POOL_CREATE_OPTIONS:=-O
compress=lz4 -O atime=off}
/usr/libexec/bsdinstall/zfsboot:/var/mail atime=on
>
> I fully agree to not violate POLA by changing the default to noatime in
> any FS. I always set noatime everywhere on systems I take care about, no
> exceptions (any user visible mail is handled via maildir/IMAP, not
> mbox). I haven't made up my mind if it would be a good idea to change
> bsdinstall to set noatime (after asking the user about it, and later
> maybe offer the possibility to use relatime in case it gets
> implemented). I think it is at least worthwile to discuss this
> possibility (including what the default setting of bsdinstall should be
> for this option).
Little late... iirc its been that way since day one of zfs support
in bsdinstall.
> --
> http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF
--
Rod Grimes rgri...@freebsd.org
Re: noatime on ufs2
On 11 Jan 2024, at 7:30, Miroslav Lachman wrote: > On 11/01/2024 09:54, Tomoaki AOKI wrote: >> On Thu, 11 Jan 2024 08:36:24 +0100 >> Alexander Leidinger wrote: > > [..] > >>> There's one possibility which nobody talked about yet... changing the >>> default to noatime at install time in fstab / zfs set. >>> >>> I fully agree to not violate POLA by changing the default to noatime in >>> any FS. I always set noatime everywhere on systems I take care about, no >>> exceptions (any user visible mail is handled via maildir/IMAP, not >>> mbox). I haven't made up my mind if it would be a good idea to change >>> bsdinstall to set noatime (after asking the user about it, and later >>> maybe offer the possibility to use relatime in case it gets >>> implemented). I think it is at least worthwile to discuss this >>> possibility (including what the default setting of bsdinstall should be >>> for this option). > > [..] > >> A different aspect of view. >> Nowadays, storages are quickly moving from HDD, aka spinning rust, to >> SSD. >> And SSD has a risk of sudden-death of wearing out. In ancient days, HDD >> dies not suddenly and at least some cases admins could have time to >> replace suspicious drives. But SSD dies basically suddenly. >> >> IMHO, this could be a valid reason to violate POLA. In limited use >> cases, atime is useful, at the cost of amplified write accesses. >> But in most cases, it doesn't have positive functionality nowadays. >> >> Anyway, we should have time to discuss whether it should be done or not >> until upcoming stable/15 branch. stable/14 is already here and it >> wouldn't be a good thing to MFC. Only *.0-RELEASE should be the point >> to introduce this, unlike discussion about vi and ee on forums. > > The default values change over time as the needs of people, programs and > hardware change. Many values for sysctls changed over time. > If "noatime" can help people to not trash SSD / SD storage, I can imagine > that bsdinstall will detect the storage type (simple guess can be made by > diskinfo -v) and offer a "noatime" option that the user can check/uncheck. > This option can be pre-selected for flash based storage. > I don't care defaults for my-self, I can change them, but sane defaults > should be beneficial for new users without much background knowledge. > > Kind regards > Miroslav Lachman I like the idea of an option in bsdinstall, but I don't think it is necessary to check the storage type. It could simply default to noatime. I think we should automatically use noatime on SD card images (where bsdinstall doesn't get used). Separately, I think a relatime option would be a good compromise, and I would probably use it. Mike
Re: noatime on ufs2
On 11/01/2024 09:54, Tomoaki AOKI wrote: On Thu, 11 Jan 2024 08:36:24 +0100 Alexander Leidinger wrote: [..] There's one possibility which nobody talked about yet... changing the default to noatime at install time in fstab / zfs set. I fully agree to not violate POLA by changing the default to noatime in any FS. I always set noatime everywhere on systems I take care about, no exceptions (any user visible mail is handled via maildir/IMAP, not mbox). I haven't made up my mind if it would be a good idea to change bsdinstall to set noatime (after asking the user about it, and later maybe offer the possibility to use relatime in case it gets implemented). I think it is at least worthwile to discuss this possibility (including what the default setting of bsdinstall should be for this option). [..] A different aspect of view. Nowadays, storages are quickly moving from HDD, aka spinning rust, to SSD. And SSD has a risk of sudden-death of wearing out. In ancient days, HDD dies not suddenly and at least some cases admins could have time to replace suspicious drives. But SSD dies basically suddenly. IMHO, this could be a valid reason to violate POLA. In limited use cases, atime is useful, at the cost of amplified write accesses. But in most cases, it doesn't have positive functionality nowadays. Anyway, we should have time to discuss whether it should be done or not until upcoming stable/15 branch. stable/14 is already here and it wouldn't be a good thing to MFC. Only *.0-RELEASE should be the point to introduce this, unlike discussion about vi and ee on forums. The default values change over time as the needs of people, programs and hardware change. Many values for sysctls changed over time. If "noatime" can help people to not trash SSD / SD storage, I can imagine that bsdinstall will detect the storage type (simple guess can be made by diskinfo -v) and offer a "noatime" option that the user can check/uncheck. This option can be pre-selected for flash based storage. I don't care defaults for my-self, I can change them, but sane defaults should be beneficial for new users without much background knowledge. Kind regards Miroslav Lachman
Re: noatime on ufs2
On Thu, 11 Jan 2024 08:36:24 +0100 Alexander Leidinger wrote: > Am 2024-01-10 22:49, schrieb Mark Millard: > > > I never use atime, always noatime, for UFS. That said, I'd never > > propose > > changing the long standing defaults for commands and calls. I'd avoid: > > [good points I fully agree on] > > There's one possibility which nobody talked about yet... changing the > default to noatime at install time in fstab / zfs set. > > I fully agree to not violate POLA by changing the default to noatime in > any FS. I always set noatime everywhere on systems I take care about, no > exceptions (any user visible mail is handled via maildir/IMAP, not > mbox). I haven't made up my mind if it would be a good idea to change > bsdinstall to set noatime (after asking the user about it, and later > maybe offer the possibility to use relatime in case it gets > implemented). I think it is at least worthwile to discuss this > possibility (including what the default setting of bsdinstall should be > for this option). > > Bye, > Alexander. > > -- > http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF A different aspect of view. Nowadays, storages are quickly moving from HDD, aka spinning rust, to SSD. And SSD has a risk of sudden-death of wearing out. In ancient days, HDD dies not suddenly and at least some cases admins could have time to replace suspicious drives. But SSD dies basically suddenly. IMHO, this could be a valid reason to violate POLA. In limited use cases, atime is useful, at the cost of amplified write accesses. But in most cases, it doesn't have positive functionality nowadays. Anyway, we should have time to discuss whether it should be done or not until upcoming stable/15 branch. stable/14 is already here and it wouldn't be a good thing to MFC. Only *.0-RELEASE should be the point to introduce this, unlike discussion about vi and ee on forums. -- Tomoaki AOKI
Re: noatime on ufs2
Am 2024-01-10 22:49, schrieb Mark Millard: I never use atime, always noatime, for UFS. That said, I'd never propose changing the long standing defaults for commands and calls. I'd avoid: [good points I fully agree on] There's one possibility which nobody talked about yet... changing the default to noatime at install time in fstab / zfs set. I fully agree to not violate POLA by changing the default to noatime in any FS. I always set noatime everywhere on systems I take care about, no exceptions (any user visible mail is handled via maildir/IMAP, not mbox). I haven't made up my mind if it would be a good idea to change bsdinstall to set noatime (after asking the user about it, and later maybe offer the possibility to use relatime in case it gets implemented). I think it is at least worthwile to discuss this possibility (including what the default setting of bsdinstall should be for this option). Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
Re: noatime on ufs2
On Thu, Jan 11, 2024 at 1:50 AM Rodney W. Grimes wrote: > > Olivier Certner wrote on > > Date: Wed, 10 Jan 2024 10:01:48 UTC : > > > What I'm saying is that, based on others' input so far, my own (long, > > > even if not as long as yours) experience and some late reflection, is > > > that "noatime" should be the default (everywhere, all mounts and all > > > FSes), and that working on "relatime" won't make any real difference for > > > most users (IOW, I think that developing "relatime" is a bad idea *in > > > general*). And I think this is a sufficiently reasonable conclusion that > > > anyone with the same inputs would conclude the same. So, if it's not the > > > case, I would be interested in knowing why, ideally. > > > > I never use atime, always noatime, for UFS. That said, I'd never propose > > changing the long standing defaults for commands and calls. I'd avoid: > > .. Very well said Mark ... > > Please folks stop tweaking defaults, especially long standing ones, > if you feel the need for noatime, set it, by all means, I have been > for 30 years > > .. what Mark said very well removed for brevity ... +1 :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: noatime on ufs2
> Olivier Certner wrote on > Date: Wed, 10 Jan 2024 10:01:48 UTC : > > > What I'm saying is that, based on others' input so far, my own (long, even > > if not as long as yours) experience and some late reflection, is that > > "noatime" should be the default (everywhere, all mounts and all FSes), and > > that working on "relatime" won't make any real difference for most users > > (IOW, I think that developing "relatime" is a bad idea *in general*). And I > > think this is a sufficiently reasonable conclusion that anyone with the > > same inputs would conclude the same. So, if it's not the case, I would be > > interested in knowing why, ideally. > > I never use atime, always noatime, for UFS. That said, I'd never propose > changing the long standing defaults for commands and calls. I'd avoid: .. Very well said Mark ... Please folks stop tweaking defaults, especially long standing ones, if you feel the need for noatime, set it, by all means, I have been for 30 years .. what Mark said very well removed for brevity ... > Mark Millard > marklmi at yahoo.com -- Rod Grimes rgri...@freebsd.org
Re: noatime on ufs2
Olivier Certner wrote on
Date: Wed, 10 Jan 2024 10:01:48 UTC :
> What I'm saying is that, based on others' input so far, my own (long, even if
> not as long as yours) experience and some late reflection, is that "noatime"
> should be the default (everywhere, all mounts and all FSes), and that working
> on "relatime" won't make any real difference for most users (IOW, I think
> that developing "relatime" is a bad idea *in general*). And I think this is a
> sufficiently reasonable conclusion that anyone with the same inputs would
> conclude the same. So, if it's not the case, I would be interested in knowing
> why, ideally.
I never use atime, always noatime, for UFS. That said, I'd never propose
changing the long standing defaults for commands and calls. 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.)
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.)
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, . . .)
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.)
Note: I've worded the above as if things are always per file system.
Command default that apply across file systems that have the feature
of allowing stored atime are also relevant. But the wording gets messy
if expanded in each relevant place above.
Picking openzfs as an example of documented uniformity . . .
https://openzfs.github.io/openzfs-docs/man/master/7/zfsprops.7.html documents:
QUOTE
atime=on|offControls whether the access time for files is updated when they are
read. Turning this property off avoids producing write traffic when reading
files and can result in significant performance gains, though it might confuse
mailers and other similar utilities. The values on and off are equivalent to
the atime and noatime mount options. The default value is on.
END QUOTE
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.
In my view , the burden to make things work relative such defaults
is not worth the consequences of making a bunch of new distinctions
in a long standing subject area.
===
Mark Millard
marklmi at yahoo.com
Re: noatime on ufs2
On Wed, Jan 10, 2024 at 12:44 PM Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > > Olivier Certner writes: > > > I've never found any compelling reason in most uses to enable "atime", > > except > > perhaps local mail but as addressed in other answers it is a relic of the > > pa > > st mostly irrelevant today. And its drawbacks are well known and can be > > seri > > ous. > > When UNIX ran on PDP-11s and disk pack sizes were measured in the > tens of megabytes, atime was very helpful in determining which files > were likely candidates for archiving to tape when the disk was > getting full. And in the Usenet days it was common to mount > /var/spool/news noatime, which eliminated a *lot* of meta-info > write traffic. > > These days, other than /var/mail, I can't think of a compelling use > for it. I've been running my Plan 9 systems with atime disabled > ever since fossil arrived (decades) without any impact. > > I don't see any issue with making noatime the default. For those > that must have it, /var/mail can be carved out as a distinct > filesystem and mounted appropriately. Just choosing the last message in the thread... I do not have a strong opinion w.r.t. atime, but I do believe that changing the default would be a POLA violation. Please look at this email thread, where the opinion w.r.t. atime seemed quite different: freebsd-hackers@ Oct. 5, 2023 Subject: copy_file_range() doesn't update the atime of an empty file I'd put a url here, but gmail always puts the subject line in here when I copy/paste the url? Basically I did not think that updating the infd's atime when copy_file_range() did not actually copy any data, but the collective disagreed, so I patched the NFSv4 client. (I do not know if markj@'s patch did get committed). They also collectively thought that Linux did a poor job w.r.t. atime. rick > > --lyndon >
Re: noatime on ufs2
Olivier Certner writes: > I've never found any compelling reason in most uses to enable "atime", except > perhaps local mail but as addressed in other answers it is a relic of the pa > st mostly irrelevant today. And its drawbacks are well known and can be seri > ous. When UNIX ran on PDP-11s and disk pack sizes were measured in the tens of megabytes, atime was very helpful in determining which files were likely candidates for archiving to tape when the disk was getting full. And in the Usenet days it was common to mount /var/spool/news noatime, which eliminated a *lot* of meta-info write traffic. These days, other than /var/mail, I can't think of a compelling use for it. I've been running my Plan 9 systems with atime disabled ever since fossil arrived (decades) without any impact. I don't see any issue with making noatime the default. For those that must have it, /var/mail can be carved out as a distinct filesystem and mounted appropriately. --lyndon
Re: noatime on ufs2
On Wed, Jan 10, 2024 at 6:36 PM Olivier Certner wrote: > Both the examples above prompt some straight objections on the current > usefulness of "atime". First, unless you've disabled building the locate > database in cron (enabled by default, on a weekly basis), access times on > directories lose most of their usefulness. Second, if using an IDS, I'm > afraid it's just game over. And even if you think you are not, > '460.pkg-checksum' at least is readily there to much complicate, or even > prevent you from, getting package usage information this way (it is enabled > by default, and on a daily basis). > > The general point here is that a single access time is inherently fragile to > interferences by multiple applications for multiple reasons. I am reading this interesting discussion and please verify my general understanding: 1. There is a request for change in core OS / FS mechanism of file access time (atime) because of problem with mailing application? 2. Linux change of approach to atime that keeps its value only around last 24h so we should also change it in FreeBSD? 3. "realtime" is the alternative solution to keep atime intact? Why change well known standardized and widely used mechanism that is here for decades? If there is a problem with an application why change core OS/FS with all possible negative consequences and not fix the application? Wouldn't that break POSIX / backward compatiblity? Thanks :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: noatime on ufs2
Hallo Olivier Certner wrote in <2367131.USjQqFH40Q@ravel>: |> I would not exactly call this a gimmick. | |I wish I hadn't used that term since it attracts too much attention \ |on itself, making people forget it was part of a sentence that was \ |quite balanced and seemingly altering their judgement. Sure. |I think you're confusing the need and the mechanism (or implementation). \ | In substance, we (Robert and I) were talking about turning "atime" \ |off *by default*. What I tried to convey is that the needs that justify \ |this mechanism are those of a minority in my view (and I'm certainly \ |not opposed to be educated if it's not true), and additionally that \ It is not true. |the "atime" mechanism addresses these needs poorly. I hate atime. In the past i always turned it off on most partitions, under FreeBSD. If i recall correctly reading FreeBSD documentation (which was my main UNIX learning factor; including the /usr/share stuff that i much admired) ignited that feeling of waste of prescious time (on a Cyrix 166+ with 49 MB RAM and a, uh, maybe 200 or ~250 MB hard disk -- i have forgotten!, i seem to recall about ~300 or 330 MB/sec memory and ~30 MB/sec cached disk performance (Linux), and i am pretty sure about the less than 5 MB/sec otherwise). I think i always used noatime by this time, on FreeBSD (whenever i read out the old IDE disks i hopefully will discover also that). I seem to recall "birth time" did not exist. Now it must be said that today i do not care that much. I do not even have a special partition for /var no more (on the laptop, at least). The memory and that incredible NVME disk are so unbelievable fast that i would not even have dreamed of it. Whereas i still do not truly look at access time myself consciously, i let it happen. (Unless it does not make sense; for example /x/music -- greetings to Kaiserslautern! -- is actually living on multiple disks, and (backup) sticks (well those: actually all), and it is only hm populated on one master (at the moment not NFS shared, but maybe later). That is then cloned everywhere. So. Hm. Ie, twenty and more years ago i surely would have agreed in that i turn(ed) off atime, but today, .. i for myself use relatime here. Also: as a general by-default policy: i do not think so. (But i am only a user.) |With that in mind, developing "relatime" to try to alleviate the shortco\ |mings of "atime" has a low ROI: It doesn't add the crucial functionality \ |most needs (like auditing) would require and doesn't even really address \ |the I/O shortcomings in some frequent scenarios. Deactivating "atime", \ Aha? Which? Today?? Well i mean writing must happen. |by contrast, doesn't require any development, suppresses all I/O overhead, \ |and doesn't suppress any functionality for an overwhelming majority \ |of uses (at least, this is my current view; other inputs welcome). Not mines. |I did not say that the needs themselves are a gimmick, e.g., having \ |a notification of new mail (although, in this case, frankly, I'm on \ |the verge of arguing it). Simply, relying on "atime" (or "relatime") \ Actually it is often distress, as i work on multiple terminals, and the reported "new" mail has often already worked when the message appears. :) |for this is unnecessary, as you must have understood reading the various \ |previous answers in this thread. | |> On Linux mount(8) from https://github.com/karelzak/util-linux says |> |>relatime |>Update inode access times relative to modify or change time. \ |>Access |>time is only updated if the previous access time was earlier than |>or equal to the current modify or change time. (Similar to \ |>noatime, |>but it doesn’t break mutt(1) or other applications that need to |>know if a file has been read since the last time it was modified) |> |> and this is what i use, except for some noatime mount points |> (/x/doc, /x/music, /x/pub, to be exact). | |It seems that the other answers (mostly those of Robert IIRC) have \ |shown that this manpage text isn't up-to-date with current practices. Ah ja? |Which need(s) of yours are you trying to address exactly by using "relat\ |ime"? I address that i do not turn off atime. Actually i do not, but get that automatically. But would otherwise. I only set noatime at times. Some utitilities even actively restore access time after they are doing their thing, in a standardized way. |Thanks and regards. I think i want to day that i would not like it if a global policy enforces noatime. Especially since the necessary changes are small, and could even be automatized easily. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: noatime on ufs2
> > Again, I'm not opposing anyone from working on "relatime" if they > > personally have a strong need and motivation. I'm not even asking for > > removing the "atime" functionality, which can have its uses. > > > > Yea, relatime has some interesting use cases: Is this binary / library in > use is one such case. The fact that you've completely omitted that use case > suggests that the analysis of atime's usefulness (or its lack) is at least > incomplete. Yes, but I never pretended to have completely analyzed the usefulness of 'atime'. See "which can have its uses" above. But I think there is already enough matter for the case of the *default value* for 'atime'. > relatime would work great on /usr/local where you have a lot of programs: > you reduce a lot of traffic. It's quite useful to know what packages are in > use or not based on when they were last accessed, not just last installed. Both the examples above prompt some straight objections on the current usefulness of "atime". First, unless you've disabled building the locate database in cron (enabled by default, on a weekly basis), access times on directories lose most of their usefulness. Second, if using an IDS, I'm afraid it's just game over. And even if you think you are not, '460.pkg-checksum' at least is readily there to much complicate, or even prevent you from, getting package usage information this way (it is enabled by default, and on a daily basis). The general point here is that a single access time is inherently fragile to interferences by multiple applications for multiple reasons. > I'm not sure this is a great notion to have everywhere. I think your > analysis needs more inputs. May be, but to me the case for the default value debate at least seems quite strong already. Regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
On Wed, Jan 10, 2024 at 3:01 AM Olivier Certner wrote: > Hi Warner, > > > It has also been used for almost as long to see if log files have changed > > if you set your MAIL variable to that. So not just for email... > > This seems to be an example in point of a "niche" scenario, both in terms > of spread of usage (even then) and the fact that it's easy to get the > functionality by other means. > Yea... tail -f does it too... But this is a useful way to get your shell to tell you when something has changed. It's a widely used trick (or has been in the past). But it really has nothing to do with atime... Just a clever use of MAIL variable. > Again, I'm not opposing anyone from working on "relatime" if they > personally have a strong need and motivation. I'm not even asking for > removing the "atime" functionality, which can have its uses. > Yea, relatime has some interesting use cases: Is this binary / library in use is one such case. The fact that you've completely omitted that use case suggests that the analysis of atime's usefulness (or its lack) is at least incomplete. > What I'm saying is that, based on others' input so far, my own (long, even > if not as long as yours) experience and some late reflection, is that > "noatime" should be the default (everywhere, all mounts and all FSes), and > that working on "relatime" won't make any real difference for most users > (IOW, I think that developing "relatime" is a bad idea *in general*). And > I think this is a sufficiently reasonable conclusion that anyone with the > same inputs would conclude the same. So, if it's not the case, I would be > interested in knowing why, ideally. > relatime would work great on /usr/local where you have a lot of programs: you reduce a lot of traffic. It's quite useful to know what packages are in use or not based on when they were last accessed, not just last installed. I'm not sure this is a great notion to have everywhere. I think your analysis needs more inputs. Warner > Regards. > > -- > Olivier Certner
Re: noatime on ufs2
> This is an interesting type of argument. Except this is not an argument to the main discussion, as apparently you haven't understood? This kind of response is disingenuous. Either you said too much, or you didn't say enough. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
Van: Olivier Certner Datum: woensdag, 10 januari 2024 11:01 Aan: Warner Losh CC: freebsd-current@freebsd.org Onderwerp: Re: noatime on ufs2 Hi Warner, > It has also been used for almost as long to see if log files have changed > if you set your MAIL variable to that. So not just for email... This seems to be an example in point of a "niche" scenario, both in terms of spread of usage (even then) and the fact that it's easy to get the functionality by other means. Again, I'm not opposing anyone from working on "relatime" if they personally have a strong need and motivation. I'm not even asking for removing the "atime" functionality, which can have its uses. What I'm saying is that, based on others' input so far, my own (long, even if not as long as yours) experience and some late reflection, is that "noatime" should be the default (everywhere, all mounts and all FSes), and that working on "relatime" won't make any real difference for most users (IOW, I think that developing "relatime" is a bad idea *in general*). And I think this is a sufficiently reasonable conclusion that anyone with the same inputs would conclude the same. So, if it's not the case, I would be interested in knowing why, ideally. Regards. -- Olivier Certner "And I think this is a sufficiently reasonable conclusion that anyone with the same inputs would conclude the same." This is an interesting type of argument. Ronald.
Re: noatime on ufs2
Hi Warner, > It has also been used for almost as long to see if log files have changed > if you set your MAIL variable to that. So not just for email... This seems to be an example in point of a "niche" scenario, both in terms of spread of usage (even then) and the fact that it's easy to get the functionality by other means. Again, I'm not opposing anyone from working on "relatime" if they personally have a strong need and motivation. I'm not even asking for removing the "atime" functionality, which can have its uses. What I'm saying is that, based on others' input so far, my own (long, even if not as long as yours) experience and some late reflection, is that "noatime" should be the default (everywhere, all mounts and all FSes), and that working on "relatime" won't make any real difference for most users (IOW, I think that developing "relatime" is a bad idea *in general*). And I think this is a sufficiently reasonable conclusion that anyone with the same inputs would conclude the same. So, if it's not the case, I would be interested in knowing why, ideally. Regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
Hi, > I would not exactly call this a gimmick. I wish I hadn't used that term since it attracts too much attention on itself, making people forget it was part of a sentence that was quite balanced and seemingly altering their judgement. I think you're confusing the need and the mechanism (or implementation). In substance, we (Robert and I) were talking about turning "atime" off *by default*. What I tried to convey is that the needs that justify this mechanism are those of a minority in my view (and I'm certainly not opposed to be educated if it's not true), and additionally that the "atime" mechanism addresses these needs poorly. With that in mind, developing "relatime" to try to alleviate the shortcomings of "atime" has a low ROI: It doesn't add the crucial functionality most needs (like auditing) would require and doesn't even really address the I/O shortcomings in some frequent scenarios. Deactivating "atime", by contrast, doesn't require any development, suppresses all I/O overhead, and doesn't suppress any functionality for an overwhelming majority of uses (at least, this is my current view; other inputs welcome). I did not say that the needs themselves are a gimmick, e.g., having a notification of new mail (although, in this case, frankly, I'm on the verge of arguing it). Simply, relying on "atime" (or "relatime") for this is unnecessary, as you must have understood reading the various previous answers in this thread. > On Linux mount(8) from https://github.com/karelzak/util-linux says > >relatime >Update inode access times relative to modify or change time. Access >time is only updated if the previous access time was earlier than >or equal to the current modify or change time. (Similar to noatime, >but it doesn’t break mutt(1) or other applications that need to >know if a file has been read since the last time it was modified.) > > and this is what i use, except for some noatime mount points > (/x/doc, /x/music, /x/pub, to be exact). It seems that the other answers (mostly those of Robert IIRC) have shown that this manpage text isn't up-to-date with current practices. Which need(s) of yours are you trying to address exactly by using "relatime"? Thanks and regards. -- Olivier Certner signature.asc Description: This is a digitally signed message part.
Re: noatime on ufs2
On Tue, Jan 9, 2024, 11:11 AM Steffen Nurpmeso wrote:
> rob...@rrbrussell.com wrote in
> <5f370bce-bcdb-47ea-aaa7-551ee092a...@app.fastmail.com>:
> |On Tue, Jan 9, 2024, at 05:13, void wrote:
> |> On Tue, Jan 09, 2024 at 09:47:59AM +0100, Olivier Certner wrote:i
> |>> So, to me, at this point, it still sounds more than a gimmick
> |>> than something really useful. If someone has a precise use case
>
> Email existence checks are in UNIX for many decades.
> In fact since 1974-11-26 when Ken Thompson added that to login(1).
> "You have new mail" is in BSD since
>
> Commit: Bill Joy
> CommitDate: 1978-11-05 19:59:54 -0800
>
It has also been used for almost as long to see if log files have changed
if you set your MAIL variable to that. So not just for email...
Warner
Start development on BSD 3
> Create reference copy of all prior development files
>
> in BSD Mail and csh(1).
> And today in bash(1), for example, there can be read
>
> /* If the user has just run a program which manipulates the
>mail file, then don't bother explaining that the mail
>file has been manipulated. Since some systems don't change
>the access time to be equal to the modification time when
>the mail in the file is manipulated, check the size also. If
>the file has not grown, continue. */
> if ((atime >= mtime) && !file_is_bigger)
> continue;
>
> /* If the mod time is later than the access time and the file
>has grown, note the fact that this is *new* mail. */
> if (use_user_notification == 0 && (atime < mtime) &&
> file_is_bigger)
> message = _("You have new mail in $_");
>
> I would not exactly call this a gimmick.
> On Linux mount(8) from https://github.com/karelzak/util-linux says
>
>relatime
>Update inode access times relative to modify or change time. Access
>time is only updated if the previous access time was earlier than
>or equal to the current modify or change time. (Similar to noatime,
>but it doesn’t break mutt(1) or other applications that need to
>know if a file has been read since the last time it was modified.)
>
> and this is what i use, except for some noatime mount points
> (/x/doc, /x/music, /x/pub, to be exact).
>
> --steffen
> |
> |Der Kragenbaer,The moon bear,
> |der holt sich munter he cheerfully and one by one
> |einen nach dem anderen runter wa.ks himself off
> |(By Robert Gernhardt)
>
>
Re: noatime on ufs2
On Tue, Jan 9, 2024 at 2:47 AM void wrote: > I was concerned that email might not work right without atime. > So far, it seems to be working OK. > Depending on how you define "correct". Deliveries won't be affected by atime setting in any way; telling if you have new mail _may_ be affected, but it would be at worst annoying (shell / MUA claims you have new mail while you don't, and even that it's only for their startup, once the shell is running it won't rely on atime). Cheers,
Re: noatime on ufs2
On Tue, Jan 9, 2024, at 04:47, void wrote: > On Mon, Jan 08, 2024 at 12:41:02PM -0800, Xin LI wrote: >>On Sun, Jan 7, 2024 at 5:27 AM void wrote: >> >>> Hi, >>> >>> Does /var/mail still need atime? >>> >>> I've installed a ufs2-based -current main-n267425-aa1223ac3afc on >>> rpi4/8BG which installs into one / . If it's mounted with noatime, >>> will it have consequences for /var/mail ? >> >> >>It doesn't matter if you don't normally receive emails locally (nowadays, >>it's rare). > > I read the periodic ones locally > >>If you do receive emails locally, it depends on what application(s) that >>you are using. > > In this type of context it'll be either exim or dma with mutt used for reading > the emails. It'll be in whatever the default format is (mbox?) set mbox_type=Maildir forces Mutt to use the Maildir format. I remember one or more of Postfix, Procmail, Mutt, and Dovecot assuming the Maildir format for any folder or spool file that ended in a /. > >>Most applications nowadays check both mtime and atime plus >>sizes of the mailbox file and do not rely on atime (because they saved the >>previous mtime). Without atime updates, some application may claim that >>you have new mail when the mailbox is not empty when they first start. >> >>That's said, if I were you and I'm using some flash based storage (with rpi >>it's highly likely) regardless if I'm using mail locally; most of the time >>the data is not really useful for anything, and it does increase the wear >>of your storage. > > Good to know. When installing, the opportunity to define partitions > didn't arise because the image was installed by dd to > media that will run the system (in this case a hard disk) > > I was concerned that email might not work right without atime. > So far, it seems to be working OK. > > My fstab in part looks like this: > > /dev/ufs/rootfs / ufs rw,noatime,async 1 1 > > (async is fine because the system won't be used for data that > needs to be kept locally, and it's connected to a UPS) > --
Re: noatime on ufs2
On Tue, Jan 9, 2024, at 05:13, void wrote: > On Tue, Jan 09, 2024 at 09:47:59AM +0100, Olivier Certner wrote:i > >> So, to me, at this point, it still sounds more than a gimmick >> than something really useful. If someone has a precise use case >> for it and motivation, than of course please go ahead. > > The only use-cases I [1] can think of are either with an email system > that needs it or with something like a webserver where there's > a team of devops working on the web service who need elevated access > and a couple of sysadmins who need root for their general job, and audit > or similar is used to log these accesses. > > But maybe there are more use-cases for atime? > > but as has been mentioned, most modern mail systems don't need it > and I'm not sure how much something like audit would. Do things > like tripwire/mtree need it? It's an interesting question. No, they use other data and checksums instead of access times. > > [1] in my limited experience. i've only seen email "needing" it > and that's only in some contexts > --
Re: noatime on ufs2
On Tue, Jan 09, 2024 at 09:47:59AM +0100, Olivier Certner wrote:i So, to me, at this point, it still sounds more than a gimmick than something really useful. If someone has a precise use case for it and motivation, than of course please go ahead. The only use-cases I [1] can think of are either with an email system that needs it or with something like a webserver where there's a team of devops working on the web service who need elevated access and a couple of sysadmins who need root for their general job, and audit or similar is used to log these accesses. But maybe there are more use-cases for atime? but as has been mentioned, most modern mail systems don't need it and I'm not sure how much something like audit would. Do things like tripwire/mtree need it? It's an interesting question. [1] in my limited experience. i've only seen email "needing" it and that's only in some contexts --
Re: noatime on ufs2
On Mon, Jan 08, 2024 at 12:41:02PM -0800, Xin LI wrote: On Sun, Jan 7, 2024 at 5:27 AM void wrote: Hi, Does /var/mail still need atime? I've installed a ufs2-based -current main-n267425-aa1223ac3afc on rpi4/8BG which installs into one / . If it's mounted with noatime, will it have consequences for /var/mail ? It doesn't matter if you don't normally receive emails locally (nowadays, it's rare). I read the periodic ones locally If you do receive emails locally, it depends on what application(s) that you are using. In this type of context it'll be either exim or dma with mutt used for reading the emails. It'll be in whatever the default format is (mbox?) Most applications nowadays check both mtime and atime plus sizes of the mailbox file and do not rely on atime (because they saved the previous mtime). Without atime updates, some application may claim that you have new mail when the mailbox is not empty when they first start. That's said, if I were you and I'm using some flash based storage (with rpi it's highly likely) regardless if I'm using mail locally; most of the time the data is not really useful for anything, and it does increase the wear of your storage. Good to know. When installing, the opportunity to define partitions didn't arise because the image was installed by dd to media that will run the system (in this case a hard disk) I was concerned that email might not work right without atime. So far, it seems to be working OK. My fstab in part looks like this: /dev/ufs/rootfs / ufs rw,noatime,async 1 1 (async is fine because the system won't be used for data that needs to be kept locally, and it's connected to a UPS) --
Re: noatime on ufs2
On Mon, Jan 8, 2024, at 14:41, Xin LI wrote: > > > On Sun, Jan 7, 2024 at 5:27 AM void wrote: >> Hi, >> >> Does /var/mail still need atime? >> >> I've installed a ufs2-based -current main-n267425-aa1223ac3afc on >> rpi4/8BG which installs into one / . If it's mounted with noatime, >> will it have consequences for /var/mail ? > > It doesn't matter if you don't normally receive emails locally (nowadays, > it's rare). > > If you do receive emails locally, it depends on what application(s) that you > are using. Most applications nowadays check both mtime and atime plus sizes > of the mailbox file and do not rely on atime (because they saved the previous > mtime). Without atime updates, some application may claim that you have new > mail when the mailbox is not empty when they first start. > > That's said, if I were you and I'm using some flash based storage (with rpi > it's highly likely) regardless if I'm using mail locally; most of the time > the data is not really useful for anything, and it does increase the wear of > your storage. > > This reminds me that -- we probably should have implemented the Linux > "relative atime" (update atime iff (atime <= mtime || atime <= ctime) || > atime is older than a day) and "no diratime" (don't update directory atime) > for UFS and make the "relatime" option the default; I had an incomplete > implementation about a decade ago somewhere but with the recent VFS changes > it's probably easier to start over. IMHO, updating atime every time when a > file is accessed is not really providing useful data (like who accessed the > file, etc.) for audit purposes and does come with performance (more write > I/O) and reliability (wear of SSD and other flash devices) cost, therefore > not generally useful in modern days. The Linux relative atime is a pretty > clever idea that has covered the most useful use case for atime (Did I > accessed the file after it was last modified) and also provided a > coarse-grained update (capped to daily, which is a reasonable compromise) to > the atime. > > Cheers, On the Linux side of things I think almost of the mail handling programs have migrated to either using MailDir or MH style mailboxes, which don't need atime, for anything local. The MDA/MTA configuration examples have all used MailDir for around a decade now. Why not make noatime the default across the whole system? Outside of mbox why is recording access time actually useful?
Re: noatime on ufs2
On Mon, 8 Jan 2024 14:12:06 -0700 Warner Losh wrote: > On Mon, Jan 8, 2024 at 1:41 PM Xin LI wrote: > > > > > > > On Sun, Jan 7, 2024 at 5:27 AM void wrote: > > > >> Hi, > >> > >> Does /var/mail still need atime? > >> > >> I've installed a ufs2-based -current main-n267425-aa1223ac3afc on > >> rpi4/8BG which installs into one / . If it's mounted with noatime, > >> will it have consequences for /var/mail ? > > > > > > It doesn't matter if you don't normally receive emails locally (nowadays, > > it's rare). > > > > If you do receive emails locally, it depends on what application(s) that > > you are using. Most applications nowadays check both mtime and atime plus > > sizes of the mailbox file and do not rely on atime (because they saved the > > previous mtime). Without atime updates, some application may claim that > > you have new mail when the mailbox is not empty when they first start. > > > > That's said, if I were you and I'm using some flash based storage (with > > rpi it's highly likely) regardless if I'm using mail locally; most of the > > time the data is not really useful for anything, and it does increase the > > wear of your storage. > > > > This reminds me that -- we probably should have implemented the Linux > > "relative atime" (update atime iff (atime <= mtime || atime <= ctime) || > > atime is older than a day) and "no diratime" (don't update directory atime) > > for UFS and make the "relatime" option the default; I had an > > incomplete implementation about a decade ago somewhere but with the recent > > VFS changes it's probably easier to start over. IMHO, updating atime every > > time when a file is accessed is not really providing useful data (like who > > accessed the file, etc.) for audit purposes and does come with performance > > (more write I/O) and reliability (wear of SSD and other flash devices) > > cost, therefore not generally useful in modern days. The Linux relative > > atime is a pretty clever idea that has covered the most useful use case for > > atime (Did I accessed the file after it was last modified) and also > > provided a coarse-grained update (capped to daily, which is a reasonable > > compromise) to the atime. > > > > I like that compromise. It will miss a lot, but that 'miss' results in > atime being good to only about a day, which for the vast majority of things > is fine. > > Warner > > > > Cheers, Looks great if possible. Maybe /usr/bin/mail would be almost all of the MUA which actually require atime and local mailboxes (under /var/mail) would usually be used for local cron-generated ones. Others would use POP or IMAP running on different computer in most cases, I think. Regards. -- Tomoaki AOKI
Re: noatime on ufs2
On Mon, Jan 8, 2024 at 1:41 PM Xin LI wrote: > > > On Sun, Jan 7, 2024 at 5:27 AM void wrote: > >> Hi, >> >> Does /var/mail still need atime? >> >> I've installed a ufs2-based -current main-n267425-aa1223ac3afc on >> rpi4/8BG which installs into one / . If it's mounted with noatime, >> will it have consequences for /var/mail ? > > > It doesn't matter if you don't normally receive emails locally (nowadays, > it's rare). > > If you do receive emails locally, it depends on what application(s) that > you are using. Most applications nowadays check both mtime and atime plus > sizes of the mailbox file and do not rely on atime (because they saved the > previous mtime). Without atime updates, some application may claim that > you have new mail when the mailbox is not empty when they first start. > > That's said, if I were you and I'm using some flash based storage (with > rpi it's highly likely) regardless if I'm using mail locally; most of the > time the data is not really useful for anything, and it does increase the > wear of your storage. > > This reminds me that -- we probably should have implemented the Linux > "relative atime" (update atime iff (atime <= mtime || atime <= ctime) || > atime is older than a day) and "no diratime" (don't update directory atime) > for UFS and make the "relatime" option the default; I had an > incomplete implementation about a decade ago somewhere but with the recent > VFS changes it's probably easier to start over. IMHO, updating atime every > time when a file is accessed is not really providing useful data (like who > accessed the file, etc.) for audit purposes and does come with performance > (more write I/O) and reliability (wear of SSD and other flash devices) > cost, therefore not generally useful in modern days. The Linux relative > atime is a pretty clever idea that has covered the most useful use case for > atime (Did I accessed the file after it was last modified) and also > provided a coarse-grained update (capped to daily, which is a reasonable > compromise) to the atime. > I like that compromise. It will miss a lot, but that 'miss' results in atime being good to only about a day, which for the vast majority of things is fine. Warner > Cheers, >
Re: noatime on ufs2
On Sun, Jan 7, 2024 at 5:27 AM void wrote: > Hi, > > Does /var/mail still need atime? > > I've installed a ufs2-based -current main-n267425-aa1223ac3afc on > rpi4/8BG which installs into one / . If it's mounted with noatime, > will it have consequences for /var/mail ? It doesn't matter if you don't normally receive emails locally (nowadays, it's rare). If you do receive emails locally, it depends on what application(s) that you are using. Most applications nowadays check both mtime and atime plus sizes of the mailbox file and do not rely on atime (because they saved the previous mtime). Without atime updates, some application may claim that you have new mail when the mailbox is not empty when they first start. That's said, if I were you and I'm using some flash based storage (with rpi it's highly likely) regardless if I'm using mail locally; most of the time the data is not really useful for anything, and it does increase the wear of your storage. This reminds me that -- we probably should have implemented the Linux "relative atime" (update atime iff (atime <= mtime || atime <= ctime) || atime is older than a day) and "no diratime" (don't update directory atime) for UFS and make the "relatime" option the default; I had an incomplete implementation about a decade ago somewhere but with the recent VFS changes it's probably easier to start over. IMHO, updating atime every time when a file is accessed is not really providing useful data (like who accessed the file, etc.) for audit purposes and does come with performance (more write I/O) and reliability (wear of SSD and other flash devices) cost, therefore not generally useful in modern days. The Linux relative atime is a pretty clever idea that has covered the most useful use case for atime (Did I accessed the file after it was last modified) and also provided a coarse-grained update (capped to daily, which is a reasonable compromise) to the atime. Cheers,
noatime on ufs2
Hi, Does /var/mail still need atime? I've installed a ufs2-based -current main-n267425-aa1223ac3afc on rpi4/8BG which installs into one / . If it's mounted with noatime, will it have consequences for /var/mail ? --
