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:
> >>>
>
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,
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
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
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
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
> 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
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.
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
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
>
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
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
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
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
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...
>
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
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.
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 \
|
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
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:
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
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,
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
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
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
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
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
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
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,
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
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
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
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
> > 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
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
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
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,
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
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
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
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
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
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
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
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
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.
> 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
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 /
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
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
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
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
> 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
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
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
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
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
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
> > 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
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
>
> 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
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
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
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
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
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,
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
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
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
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
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
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
> >>
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
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
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 ?
--
75 matches
Mail list logo
