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 ty
Am Sun, 14 Jan 2024 20:34:12 -0800
Cy Schubert schrieb:
> In message om>
> , Rick Macklem writes:
> > On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop =
> > wrote:
> > >
> > >
> > > Van: FreeBSD User
> > > Datum: 13 januari 2024 19:34
> > > Aan: FreeBSD CURRENT
> > > Onderwerp: NFSv4
In message
, Rick Macklem writes:
> On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop =
> wrote:
> >
> >
> > Van: FreeBSD User
> > Datum: 13 januari 2024 19:34
> > Aan: FreeBSD CURRENT
> > Onderwerp: NFSv4 crash of CURRENT
> >
> > Hello,
> >
> > running CURRENT client (FreeBSD 15.0-CURRENT #
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 t
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 d
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 me
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
quic
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 deactiva
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 aspects
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
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 *anyt
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
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
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
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 dif
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 i
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 archi
Am Mon, 8 Jan 2024 01:33:53 +0100 (CET)
Felix Reichenberger schrieb:
> > Hello,
> >
> > I've got a problem with recent CURRENT, running vnet JAILs.
> > FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET
> > 2024 amd64
> >
> > Main Host has IPFW configured and is open for
Am Sat, 13 Jan 2024 19:41:30 -0800
Rick Macklem schrieb:
> On Sat, Jan 13, 2024 at 12:39 PM Ronald Klop wrote:
> >
> >
> > Van: FreeBSD User
> > Datum: 13 januari 2024 19:34
> > Aan: FreeBSD CURRENT
> > Onderwerp: NFSv4 crash of CURRENT
> >
> > Hello,
> >
> > running CURRENT client (FreeBSD 15
23 matches
Mail list logo
