From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D510C3A5A2 for ; Tue, 3 Sep 2019 21:17:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 49BE521881 for ; Tue, 3 Sep 2019 21:17:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726858AbfICVR5 (ORCPT ); Tue, 3 Sep 2019 17:17:57 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:41590 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726375AbfICVR5 (ORCPT ); Tue, 3 Sep 2019 17:17:57 -0400 Received: from callcc.thunk.org (guestnat-104-133-0-96.corp.google.com [104.133.0.96] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x83LHmaX031393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 3 Sep 2019 17:17:49 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id E453442049E; Tue, 3 Sep 2019 17:17:47 -0400 (EDT) Date: Tue, 3 Sep 2019 17:17:47 -0400 From: "Theodore Y. Ts'o" To: Deepa Dinamani Cc: Qian Cai , Jeff Layton , Alexander Viro , Linux FS-devel Mailing List , Linux Kernel Mailing List , Ext4 Developers List , Andreas Dilger , Arnd Bergmann Subject: Re: "beyond 2038" warnings from loopback mount is noisy Message-ID: <20190903211747.GD2899@mit.edu> References: <1567523922.5576.57.camel@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 03, 2019 at 09:18:44AM -0700, Deepa Dinamani wrote: > > This prints a warning for each inode that doesn't extend limits beyond > 2038. It is rate limited by the ext4_warning_inode(). > Looks like your filesystem has inodes that cannot be extended. > We could use a different rate limit or ignore this corner case. Do the > maintainers have a preference? We need to drop this commit (ext4: Initialize timestamps limits), or at least the portion which adds the call to the EXT4_INODE_SET_XTIME macro in ext4.h. I know of a truly vast number of servers in production all over the world which are using 128 byte inodes, and spamming the inodes at the maximum rate limit is a really bad idea. This includes at some major cloud data centers where the life of individual servers in their data centers is well understood (they're not going to last until 2038) and nothing stored on the local Linux file systems are long-lived --- that's all stored in the cluster file systems. The choice of 128 byte inode was deliberately chosen to maximize storage TCO, and so spamming a warning at high rates is going to be extremely unfriendly. In cases where the inode size is such that there is no chance at all to support timestamps beyond 2038, a single warning at mount time, or maybe a warning at mkfs time might be acceptable. But there's no point printing a warning time each time we set a timestamp on such a file system. It's not going to change, and past a certain point, we need to trust that people who are using 128 byte inodes did so knowing what the tradeoffs might be. After all, it is *not* the default. - Ted