linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Deepa Dinamani <deepa.kernel@gmail.com>
Cc: Qian Cai <cai@lca.pw>, Jeff Layton <jlayton@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: "beyond 2038" warnings from loopback mount is noisy
Date: Tue, 3 Sep 2019 17:17:47 -0400	[thread overview]
Message-ID: <20190903211747.GD2899@mit.edu> (raw)
In-Reply-To: <CABeXuvoPdAbDr-ELxNqUPg5n84fubZJZKiryERrXdHeuLhBQjQ@mail.gmail.com>

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

  parent reply	other threads:[~2019-09-03 21:17 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-03 15:18 "beyond 2038" warnings from loopback mount is noisy Qian Cai
2019-09-03 16:18 ` Deepa Dinamani
2019-09-03 16:36   ` Deepa Dinamani
2019-09-03 18:15     ` Qian Cai
2019-09-03 19:39       ` Andreas Dilger
2019-09-03 19:50         ` Arnd Bergmann
2019-09-03 21:13           ` Qian Cai
2019-09-03 21:17   ` Theodore Y. Ts'o [this message]
2019-09-03 21:31     ` Deepa Dinamani
2019-09-03 21:48       ` Arnd Bergmann
2019-09-03 22:38         ` Theodore Y. Ts'o
2019-09-03 22:47           ` Deepa Dinamani
2019-09-03 23:03             ` Theodore Y. Ts'o
2019-09-04  4:50         ` Deepa Dinamani
2019-09-04 12:58           ` Theodore Y. Ts'o
2019-09-04 13:21             ` Reindl Harald
2019-09-04 14:25             ` Deepa Dinamani
2019-09-03 22:16       ` Theodore Y. Ts'o
2019-09-03 21:52     ` Reindl Harald
2019-09-04 15:02       ` [PATCH] ext4: Reduce ext4 timestamp warnings Deepa Dinamani
2019-09-04 18:39         ` Andreas Dilger
2019-09-04 20:56           ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190903211747.GD2899@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=arnd@arndb.de \
    --cc=cai@lca.pw \
    --cc=deepa.kernel@gmail.com \
    --cc=jlayton@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).