From nobody Thu Jan 11 22:01:21 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 4T9zCM0f4Yz56b7h for ; Thu, 11 Jan 2024 22:01:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 4T9zCL6615z4KRq for ; Thu, 11 Jan 2024 22:01:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-40d6b4e2945so67857605e9.0 for ; Thu, 11 Jan 2024 14:01:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1705010493; x=1705615293; 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=F6zr19gB6JE3cDJs01yzwr0q0xpjVlb9lYfI8MvDV9I=; b=PDGqSt/0dtKI7KOdhAjBHljT07a0pkovQd5CMaqFkx9fyPw2fgo4Pb1mZ10pFTtR5n Ou2f1khl06+zvRu/HxgMVbsCSqsNFrlfY2G1aK9GUHFfHOtRI7TjZQO4vdO79Fm4giCk bcb/DEH3pRaQ8+oAwGze3VyYl5/PAPP5Yzcgl63VfUnhQ3kkiBsrmSSiRY+XgEPcuk6U S9Z20mb0voyOtEW81MYUu4PPj157/1k4mWGqo5qqVSFgeJ/WzhboPFrmf5Iup4yKdwyR XhtRvw2SDRMQWI5BpzFCbXZF02hdh3uyf0NqNxBwH1niGY8q6r9vckoZxmr63gPZd9bq Gdlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705010493; x=1705615293; 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=F6zr19gB6JE3cDJs01yzwr0q0xpjVlb9lYfI8MvDV9I=; b=BgR5fIFzwb5YE2FB2Vv1RP818wyNPQthfydaRGfpVXBJe5Jeqd87MLZ+DoD2xul1d/ s4T51VKim7c5PFXsCT0Mm+y/SVvE01LkBaiXziBjvM38ajY594iv2E+pFTIYF494OFQw P9b6vD19EaAKtOPUkTqcFxFYsUYweCnWhSijGZBPDwyJScDpE0mOrONOusNlxSgwpA54 xWEQ+JqGtawughKhP3u5Wqy5BjCdU2G04YAX4La0HZ4kJnginTIQyNpCwmb2OO3uadbq KaSeoMB4e6IYxtPCBxzN88C26orop96GHZgDY/rzquKz68r/+VnfcR4pzg3r1pZ7pX4J 5YHQ== X-Gm-Message-State: AOJu0Yy6VQlHfLpp9DPl0G47P/iX9MC8raJK8wm7cw/cV2WgsKkkldG8 CSPq/H+AvlHbe287GRcr5gFyw8r22hmWhxaTWiyy25nGwyeXTg== X-Google-Smtp-Source: AGHT+IHQ+itKzg3uzkaKjtWCgFJHKq6RX/ZwDk9l+An6z8nxWa70osR+TqRfLpC5/uhI1q1+A8qOLGTsrJHQ/GiYFOk= X-Received: by 2002:a05:600c:c9:b0:40e:629a:b7c9 with SMTP id u9-20020a05600c00c900b0040e629ab7c9mr183468wmm.40.1705010492502; Thu, 11 Jan 2024 14:01:32 -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: <20240111175430.e8070ef9415a092ac1a03a1c@dec.sakura.ne.jp> <233b0bd9-3867-479b-a265-21bf5df0f6ff@quip.cz> <5A74E928-2F4A-4BD6-8B77-837B793055C3@karels.net> In-Reply-To: <5A74E928-2F4A-4BD6-8B77-837B793055C3@karels.net> From: Warner Losh Date: Thu, 11 Jan 2024 15:01:21 -0700 Message-ID: Subject: Re: noatime on ufs2 To: Mike Karels Cc: Miroslav Lachman <000.fbsd@quip.cz>, Tomoaki AOKI , Current FreeBSD Content-Type: multipart/alternative; boundary="000000000000be8c39060eb2b0c2" X-Rspamd-Queue-Id: 4T9zCL6615z4KRq 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] --000000000000be8c39060eb2b0c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 11, 2024 at 6:59=E2=80=AFAM 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, HD= D > >> 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 no= t > >> 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 an= d > 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 --000000000000be8c39060eb2b0c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 11, 2024 at 6:59=E2=80=AF= AM Mike Karels <mike@karels.net&g= t; 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 <Alexander@Leidinger.net> wrote:
>
> [..]
>
>>> There's one possibility which nobody talked about yet... c= hanging the
>>> default to noatime at install time in fstab / zfs set.
>>>
>>> I fully agree to not violate POLA by changing the default to n= oatime 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 ide= a to change
>>> bsdinstall to set noatime (after asking the user about it, and= later
>>> maybe offer=C2=A0 the possibility to use relatime in case it g= ets
>>> 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 t= o
>> 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 nowa= days.
>>
>> Anyway, we should have time to discuss whether it should be done o= r not
>> until upcoming stable/15 branch. stable/14 is already here and it<= br> >> wouldn't be a good thing to MFC. Only *.0-RELEASE should be th= e point
>> to introduce this, unlike discussion about vi and ee on forums. >
> The default values change over time as the needs of people, programs a= nd 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 ca= n be made by diskinfo -v) and offer a "noatime" option that the u= ser can check/uncheck. This option can be pre-selected for flash based stor= age.
> I don't care defaults for my-self, I can change them, but sane def= aults 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 nec= essary
to check the storage type.=C2=A0 It could simply default to noatime.

I think we should automatically use noatime on SD card images (where bsdins= tall
doesn't get used).

Separately, I think a relatime option would be a good compromise, and I wou= ld
probably use it.

I think these are sens= ible steps. We already do something similar for ZFS.

Warner=C2=A0
--000000000000be8c39060eb2b0c2--