From nobody Thu Jan 11 13:58:56 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 4T9mVj2v8tz55pRn for ; Thu, 11 Jan 2024 13:59:09 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T9mVj0wXhz4MD2 for ; Thu, 11 Jan 2024 13:59:09 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 40BDwvoU054960; Thu, 11 Jan 2024 07:58:57 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1704981537; bh=NDmKjn+kx+2dJwpwB9UEe4Bae3kw2gQQV2CVpQ2PPnQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=hF1Si5/OQvW09awwy5uMDGvFxNtihp7zSEhf20xAOsZY8MAiR7bcK6GO6WV6F9IQf QRPCVn0b/DyOlJOXK7rTDqqTe356pkynr5gkhuc82PQUWT9q566oRbskS6tCKZSUmL 4DV0pwFTzvoftkNkzpR5jHx5fqnC2vFx0fgKGcyIQ1QHHKG4+8eGUB8rvBVEWX2RLR +gkjzgQFZQIyAldBXSUcl1BKasersTXOXQ489yNgtJtTFPXljk274f1LUiANoCTa3U hUrrR/Nr+530iEMylSNNEqHI2iCKsFAhl0fr8bncZoEfcm3EH0t916u0+i1oBKoH+w KFIh3vHZH5qTA== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id GuglFSH0n2Wu1gAAs/W3XQ (envelope-from ); Thu, 11 Jan 2024 07:58:57 -0600 From: Mike Karels To: Miroslav Lachman <000.fbsd@quip.cz> Cc: Tomoaki AOKI , Current FreeBSD Subject: Re: noatime on ufs2 Date: Thu, 11 Jan 2024 07:58:56 -0600 X-Mailer: MailMate (1.14r6015) Message-ID: <5A74E928-2F4A-4BD6-8B77-837B793055C3@karels.net> In-Reply-To: <233b0bd9-3867-479b-a265-21bf5df0f6ff@quip.cz> References: <20240111175430.e8070ef9415a092ac1a03a1c@dec.sakura.ne.jp> <233b0bd9-3867-479b-a265-21bf5df0f6ff@quip.cz> 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 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4T9mVj0wXhz4MD2 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:16509, ipnet:3.16.0.0/14, country:US] 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 imagi= ne 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/unc= heck. 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 neces= sary to check the storage type. It could simply default to noatime. I think we should automatically use noatime on SD card images (where bsdi= nstall doesn't get used). Separately, I think a relatime option would be a good compromise, and I w= ould probably use it. Mike