From nobody Tue Jun 09 22:10:45 2026 X-Original-To: dev-commits-src-branches@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 4gZjlq0VJtz6gkfK; Tue, 09 Jun 2026 22:10:47 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gZjlp6DyKz3GSR; Tue, 09 Jun 2026 22:10:46 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1781043046; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1Zy8VxcUwpq3Y/gmZaOIOjrB5X1ZvbuXkOATuLX05P8=; b=UFcSiHReQdqJWDPAl9Vgl+AhQfNWO8erXCbbRkbUb8p0IudElVAxvtuAeJRHrOKHDvIKV3 9981Z8QH1ptfyjcd71WX6w73OwOAseu9fgQ66pwscWQ3ef+YPSfvanFWD6SVqdJ801oE0m v2GOIpaxpS0nbtqzujx74R4dZIXpgb3FmtjHGAZ6EJZqHnggjdiTSUsBL7bZXLqv4sZxtb WdK1X49dKjHqR4CKhgI/KfWu545qOLV1e+DZBmL2M0NwxI7YmDCMuPJ27AtLeBm4exFEeA Mn7xh2DW+NEznm+Dnu3s8D0tgKhaU+3gWLJ2ZTkOqtBjFRexfxrnyq0ZX8o2Rw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1781043046; a=rsa-sha256; cv=none; b=AXWiZhUwTM96/hDP760uFNkYuhnE395n1CBfoznh/JeTv95avJQvLKuEjV9Uj23gos7/3T 4xWbAOp/mqKvlVGUU6EnhlwgAqfxdgQMPIFCv61j7CLpqv5BOBR0ze6HRzEvivqj2C6b43 SALRRB8ifEKPDztbxu3VSOhpdW5Q9DtdS7a4zyCug6HhojFSH2xJW2RvF8oxpoQkoslwxy Oe/5sVBFozNrbth85OyxGihcu8XD3iiolfUT/eMvxUmgFtityrdsRqXvqPYE+4VZq6LhwN ZbwWKBGYtaNMzAhVlpr/M/ZtLj1H3ZD7CRI3RgaRNYwH35N/msr10/VC79E5mQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1781043046; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1Zy8VxcUwpq3Y/gmZaOIOjrB5X1ZvbuXkOATuLX05P8=; b=pq30tOcFjmm1mZrXkiWoAaCnUy4s7+9KW2QweScxtHPXd7tnw2FExyRoos02VnIERMXZHG b58wH8S8IcP/FVU/8KqTA2T1ylsUKoKWSKe+JEwnURuBliioVOPXgvItiKmO1UXvX0OryT jQZGdbjJoXWo973kxqFzwe14A1GGSXE0Rsh8GW/xv6IyVrorMPYZU/LW4dvRpVjqIF31r8 1b2f6ttOnO7sfU/GHXM2cZcDJhQyqBKvVf2JSWXJff/GeVyuKk0trRsbT5ezy+aA7OT2ve bJqvk5MUcnhU/sUmOkFkhb94bwpLC/oICjT3PtoxnEZgwkcwEu2h7xGJZavKHQ== Received: from [10.9.4.95] (unknown [209.182.120.176]) (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 did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4gZjlp332YznjS; Tue, 09 Jun 2026 22:10:46 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <6fd7b96b-c5c4-4987-8ca8-f227e1066c9f@FreeBSD.org> Date: Tue, 9 Jun 2026 17:10:45 -0500 List-Id: Commits to the stable branches of the FreeBSD src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-branches List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-branches@freebsd.org Sender: owner-dev-commits-src-branches@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: a64877b140fe - stable/15 - Avoid incorrect UFS1 timestamp corrections when system clock fails at boot. To: Kirk McKusick , src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-branches@FreeBSD.org References: <6a288526.24868.173d902d@gitrepo.freebsd.org> Content-Language: en-US From: Kyle Evans In-Reply-To: <6a288526.24868.173d902d@gitrepo.freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/9/26 16:27, Kirk McKusick wrote: > The branch stable/15 has been updated by mckusick: > > URL: https://cgit.FreeBSD.org/src/commit/?id=a64877b140fe0bf374cc96c95f374894c1627a32 > > commit a64877b140fe0bf374cc96c95f374894c1627a32 > Author: Kirk McKusick > AuthorDate: 2026-06-01 23:48:21 +0000 > Commit: Kirk McKusick > CommitDate: 2026-06-09 21:26:51 +0000 > > Avoid incorrect UFS1 timestamp corrections when system clock fails at boot. > > Git 1111a44301da - main - Defer the January 19, 2038 date limit in > UFS1 file systems to February 7, 2106 - did so by changing the UFS1 > 32-bit signed timestamps to unsigned. With this change, time stamps > from before January 1, 1970 went from being negative numbers to > large positive numbers implying times in the future. When such a > time stamp is encountered when an inode is read into memory or when > it is encountered by fsck, its timestamp is replaced with the > kernel's current time. > > Andre Albsmeier reported that he had a machine reboot after a power > failure and the battery that maintained its real-time clock had > died. The result was that the system booted with the time set to > five years earlier (absent a real-time clock value, the boot ROM > used the time that the boot ROM had last been updated). The net > result was that fsck reset the time stamps of all files newer than > five years old to the five year old time. > > Andres's original request was for a flag in the file system superblock > to say that there are no timestamps from before 1970 in the file > system, so there shouldn't be anything to fix because of the signed > to unsigned switch. But this assumes that no one every does an rsync > or extracts a tar file or restores a dump that introduces an incorrect > time stamp on their system. So this approach was not taken. > > This change compares the system's version of the current time to > the last modification time in the file system superblock. If the > current time is earlier than that time then use the last modification > time in the superblock as the value for the current time. There > should be no files in the file system with times newer than the > last modification time in the superblock. > > The superblock time stamp is updated in the in-memory superblock > every time any change is made to anything in the file system. The > superblock is written to the disk every 30 seconds, so it may be > off by up to 30 seconds plus the time it sits in the disk cache > waiting to be written if the system has an unclean shutdown (such > as a power failure). Thus, the worst case scenario with this change > is that files written in the last 30 seconds plus disk cache delay > time before the crash may have their times adjusted back by up to > 30 seconds plus the disk cache delay time. > I have a related question that came up while I was working on a patch for ZFS[0] to set a mount-time for those of us with broken RTCs. The current version of mountroot[1] calls inittodr() *after* the root is mounted, which means that anything needing to pull a timestamp when the root is mounted gets a time <= 10 (probably 1). In ZFS, this results in an uberblock update that leaves a bogus timestamp around until another update occurs, and I'm not sure that that's really OK. I'm wondering if we should consider splitting inittodr() or something to try and read the RTC before we have a root, and 'fixing' the clock after root is mounted if we need a hint from the rootfs? I don't know if any of this matters for UFS. Thanks, Kyle Evans [0] https://github.com/openzfs/zfs/pull/18645 [1] https://cgit.freebsd.org/src/tree/sys/kern/vfs_mountroot.c?id=01c8e2e33df81b242d73a23de49a6b61f33c24c1#n1105