From nobody Wed Jan 10 16:55:40 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T9DT61Lxnz55N0l for ; Wed, 10 Jan 2024 16:55:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9DT535Mkz3xlh for ; Wed, 10 Jan 2024 16:55:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5572a9b3420so9159886a12.1 for ; Wed, 10 Jan 2024 08:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704905752; x=1705510552; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oJS2ZHb7Ufva8WkIJ6uaco7UFqBj369UYUBAXCyR7S0=; b=GwVBMFyE2WpvphNfigntSyCpy+eOFFJAI3RlQoh804RhvxZmbNbPRw2HLtNQuwY/C9 5L+Tr6qnZGHYSX5cRB/uMrSxmDjJhOKGVmulhe1QBz9c4LiTOEPSBR1MkPS0/qIIV9de BrQLK0Y9d/MtNU2erCArTlTpU0s/ERtCo4N5aHAMIPmsVo0C8jo+eLXnXjGFlX0pu8Cg 6uve61+JaJ04z4UgMtU/9bj+zn6hcOiaXjdi5EG3TuhBzT1TWpKeD4QSgyGzbUAoyjEv xGWy5soOEOjOnkChG/APGCpcnLnXTO+v7eAth5Vdye5i2aK3BJSxUKCRDDkAnEYNpams X7Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704905752; x=1705510552; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oJS2ZHb7Ufva8WkIJ6uaco7UFqBj369UYUBAXCyR7S0=; b=UY0GmZX+/QY6/IvSb/dPtd/A0lX2SR2MFUCenixiu1r5PEeYj1jA2nugK1Qzd1LdQ1 A58/tHxX7idn5zxvfHee35BvdZas/WE8O00uU3J+MACHyJ4WgvoFOHW/N7vh85Pod+Mc DhP+o7MGzyiBFZYK6UngnefyH5t1zUAE5g0YsMVWRD9MBpvdma259ZbpVv/aYftlKg46 kEinDIjdAOMwttd91IlO7o3Mqj7D3iJXMCkHSbzckciuw5/gIVpLTMxzwZAAfmWCsne8 xWSFV5at8+2NSZf7XTfN+gkNH/L6Y2QQLCPe9huz/FvXRMuAWH+Zzn1U2XwxiGJ4KTaN rUPw== X-Gm-Message-State: AOJu0YzwdSfLK7s+zJ8dgdujjqrxLlL4UFGs1O2zDDqfNhbx5ehF1nVs N/ARdrJHBZ6abqzR6Mp/p5EKB3/nn+60Y0NYG4jBK0s6NBKUtCEDe/yJpxhmtf4= X-Google-Smtp-Source: AGHT+IGd08KPNBYdqtBjVPeVlBumbHcx5icyh6NQ/smOSG+e+jbWYoQrLlmKF8DXCieLSs3RLzawLVWu3XrPKgeA7JU= X-Received: by 2002:a17:906:d7a8:b0:a2a:c113:2677 with SMTP id pk8-20020a170906d7a800b00a2ac1132677mr356100ejb.61.1704905751808; Wed, 10 Jan 2024 08:55:51 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20240109174318.MCIB6yhn@steffen%sdaoden.eu> <1749331.ETpRK2a2Mi@ravel> In-Reply-To: <1749331.ETpRK2a2Mi@ravel> From: Warner Losh Date: Wed, 10 Jan 2024 09:55:40 -0700 Message-ID: Subject: Re: noatime on ufs2 To: Olivier Certner Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000b65b7e060e9a4da5" X-Rspamd-Queue-Id: 4T9DT535Mkz3xlh X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --000000000000b65b7e060e9a4da5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 10, 2024 at 3:01=E2=80=AFAM Olivier Certner = wrote: > Hi Warner, > > > It has also been used for almost as long to see if log files have chang= ed > > 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, eve= n > if not as long as yours) experience and some late reflection, is that > "noatime" should be the default (everywhere, all mounts and all FSes), an= d > 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*). An= d > 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 b= e > 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 --000000000000b65b7e060e9a4da5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 10, 2024 at 3:01=E2=80=AF= AM Olivier Certner <olce@freebsd.org= > wrote:
= Hi Warner,

> It has also been used for almost as long to see if log files have chan= ged
> 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.

Y= ea... 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 b= een in the past). But it really has nothing to do with atime... Just a clev= er use of MAIL variable.
=C2=A0
Again, I'm not opposing anyone from working on "relatime" if = they personally have a strong need and motivation.=C2=A0 I'm not even a= sking for removing the "atime" functionality, which can have its = uses.

Yea, relatime has some interestin= g use cases: Is this binary / library in use is one such case. The fact tha= t you've completely omitted that use case suggests that the analysis of= atime's usefulness (or its lack) is at least incomplete.
=C2= =A0
What I'm saying is that, based on others' input so far, my own (lon= g, even if not as long as yours) experience and some late reflection, is th= at "noatime" should be the default (everywhere, all mounts and al= l FSes), and that working on "relatime" won't make any real d= ifference for most users (IOW, I think that developing "relatime"= is a bad idea *in general*).=C2=A0 And I think this is a sufficiently reas= onable conclusion that anyone with the same inputs would conclude the same.= =C2=A0 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 t= hey were last accessed, not just last installed.

I= 'm not sure this is a great notion to have everywhere. I think your ana= lysis needs more inputs.

Warner
=C2=A0
Regards.

--
Olivier Certner
--000000000000b65b7e060e9a4da5--