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: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b
On Tue, 30 Jan 2024 08:12:23 -0800
David Wolfskill wrote:
> On Tue, Jan 30, 2024 at 03:49:54PM +, Gary Jennejohn wrote:
> > ...
> > I use 'shutdown -p now' and it's never failed to power down my computers.
> >
>
> I could say the same about "poweroff", up to the main-n267808-197944948e62
> -> main-n267841-0b3f9e435f2b transition. And I probably wouldn't
> have mentioned anything, except that each of the 3 machines (one
> headless build machine; 2 laptops) I tested exhibited the same change.
>
> Note, too, from src/sbin/shutdown/shutdown.c:
>
> /*
> * Test for the special case where the utility is called as
> * "poweroff", for which it runs 'shutdown -p now'.
> */
> if ((p = strrchr(argv[0], '/')) == NULL)
> p = argv[0];
> else
> ++p;
> if (strcmp(p, "poweroff") == 0) {
> if (getopt(argc, argv, "") != -1)
> usage((char *)NULL);
> argc -= optind;
> argv += optind;
> if (argc != 0)
> usage((char *)NULL);
> dopower = 1;
> offset = 0;
> (void)time();
> goto poweroff;
>
> (So I believe we are referring to the same code paths, whether by
> "shutdown -p now" or "poweroff".)
>
Interesting, I wasn't aware of this. Reading shutdown(8) I see that
poweroff is equivalent to shutdown -p now. Thanks!
--
Gary Jennejohn
Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b
On Tue, Jan 30, 2024 at 03:49:54PM +, Gary Jennejohn wrote:
> ...
> I use 'shutdown -p now' and it's never failed to power down my computers.
>
I could say the same about "poweroff", up to the main-n267808-197944948e62
-> main-n267841-0b3f9e435f2b transition. And I probably wouldn't
have mentioned anything, except that each of the 3 machines (one
headless build machine; 2 laptops) I tested exhibited the same change.
Note, too, from src/sbin/shutdown/shutdown.c:
/*
* Test for the special case where the utility is called as
* "poweroff", for which it runs 'shutdown -p now'.
*/
if ((p = strrchr(argv[0], '/')) == NULL)
p = argv[0];
else
++p;
if (strcmp(p, "poweroff") == 0) {
if (getopt(argc, argv, "") != -1)
usage((char *)NULL);
argc -= optind;
argv += optind;
if (argc != 0)
usage((char *)NULL);
dopower = 1;
offset = 0;
(void)time();
goto poweroff;
(So I believe we are referring to the same code paths, whether by
"shutdown -p now" or "poweroff".)
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Do these ends really justify those means?
See https://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b
On Tue, 30 Jan 2024 07:10:45 -0800 David Wolfskill wrote: > On Tue, Jan 30, 2024 at 03:56:16PM +0100, Tomek CEDRO wrote: > > On Tue, Jan 30, 2024 at 3:49?PM David Wolfskill wrote: > > > The machines where I track head (& stable/14) daily get powered off once > > > they have finished their work for the day; this is done via "poweroff". > > > > > > I noticed (this morning) that one of them never actually powered off > > > yesterday. After today's exercises (including the reboot & subsequent > > > poweroff), I saw on the (serial) console: > > > > Have you tried hw.efi.poweroff=0 in /boot/loader.conf ? :-) > > > > No; I don't mess with /boot/*.conf without a (plausibly good) reason. :-) > > But I can experiment... so I'm trying it now. > ... > Hmm... I don't see any difference in behavior. > > These systems each boot using BIOS (vs. UEFI), in case that's relevant. > I use 'shutdown -p now' and it's never failed to power down my computers. -- Gary Jennejohn
Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b
On Tue, Jan 30, 2024 at 03:56:16PM +0100, Tomek CEDRO wrote: > On Tue, Jan 30, 2024 at 3:49 PM David Wolfskill wrote: > > The machines where I track head (& stable/14) daily get powered off once > > they have finished their work for the day; this is done via "poweroff". > > > > I noticed (this morning) that one of them never actually powered off > > yesterday. After today's exercises (including the reboot & subsequent > > poweroff), I saw on the (serial) console: > > Have you tried hw.efi.poweroff=0 in /boot/loader.conf ? :-) > No; I don't mess with /boot/*.conf without a (plausibly good) reason. :-) But I can experiment... so I'm trying it now. ... Hmm... I don't see any difference in behavior. These systems each boot using BIOS (vs. UEFI), in case that's relevant. Peace, david -- David H. Wolfskill da...@catwhisker.org Do these ends really justify those means? See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b
On Tue, Jan 30, 2024 at 3:49 PM David Wolfskill wrote: > The machines where I track head (& stable/14) daily get powered off once > they have finished their work for the day; this is done via "poweroff". > > I noticed (this morning) that one of them never actually powered off > yesterday. After today's exercises (including the reboot & subsequent > poweroff), I saw on the (serial) console: Have you tried hw.efi.poweroff=0 in /boot/loader.conf ? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b
The machines where I track head (& stable/14) daily get powered off once they have finished their work for the day; this is done via "poweroff". I noticed (this morning) that one of them never actually powered off yesterday. After today's exercises (including the reboot & subsequent poweroff), I saw on the (serial) console: | ... | unknown: wake_prep disabled wake for \_SB_.PCI3.SR3A (S5) | unknown: wake_prep disabled wake for \_SB_.PCI3.SR3B (S5) | unknown: wake_prep disabled wake for \_SB_.PCI3.SR3C (S5) | unknown: wake_prep disabled wake for \_SB_.PCI3.SR3D (S5) | | The operating system has halted. | Please press any key to reboot. So I hit "Enter" and then saw: | | acpi0: Powering system off (and heard the fans stop spinning). And that recurred this morning. So I believe that the issue arose in the transition from what the machine had built on Sunday: FreeBSD 15.0-CURRENT #36 main-n267808-197944948e62: Sun Jan 28 16:22:34 UTC 2024 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1500012 1500012 to what it built on Monday: FreeBSD 15.0-CURRENT #37 main-n267841-0b3f9e435f2b: Mon Jan 29 12:17:47 UTC 2024 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1500012 1500012 Glancing at the typescript from Monday's update/build (197944948e62..0b3f9e435f2b), it looks to me as if there was a fair amount of "churn" in boot-related code, so I will look further into that as time permits. Peace, david -- David H. Wolfskill da...@catwhisker.org Do these ends really justify those means? See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
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
