linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Deepa Dinamani <deepa.kernel@gmail.com>, 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>
Subject: Re: "beyond 2038" warnings from loopback mount is noisy
Date: Tue, 3 Sep 2019 18:38:15 -0400	[thread overview]
Message-ID: <20190903223815.GH2899@mit.edu> (raw)
In-Reply-To: <CAK8P3a0AcPzuGeNFMW=ymO0wH_cmgnynLGYXGjqyrQb65o6aOw@mail.gmail.com>

On Tue, Sep 03, 2019 at 11:48:14PM +0200, Arnd Bergmann wrote:
> I think the warning as it was intended makes sense, the idea
> was never to warn on every inode update for file systems that
> cannot handle future dates, only to warn when we
> 
> a) try to set a future date
> b) fail to do that because the space cannot be made available.

What do you mean by "try to set a future date"?  Do you mean a trying
to set a date after 2038 (when it can no longer fit in a signed 32-bit
value)?  Because that's not what the commit is currently doing.....

> I would prefer to fix it on top of the patches I already merged.
> 
> Maybe something like:
> 
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index 9e3ae3be3de9..5a971d1b6d5e 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -835,7 +835,9 @@ do {
>                                  \
>                 }
>          \
>         else    {\
>                 (raw_inode)->xtime = cpu_to_le32(clamp_t(int32_t,
> (inode)->xtime.tv_sec, S32_MIN, S32_MAX));    \
> -               ext4_warning_inode(inode, "inode does not support
> timestamps beyond 2038"); \
> +               if (((inode)->xtime.tv_sec != (raw_inode)->xtime) &&     \
> +                   ((inode)->i_sb->s_time_max > S32_MAX))
>          \
> +                       ext4_warning_inode(inode, "inode does not
> support timestamps beyond 2038"); \
>         } \
>  } while (0)

Sure, that's much less objectionable.

> However, I did expect that people might have legacy ext3 file system
> images that they mount, and printing a warning for each write would
> also be wrong for those.

I guess I'm much less convinced that 10-15 years from now, there will
be many legacy ext3 file systems left.  Storage media doesn't last
that long, and if file systems get moved around, e2fsck will be run at
least once, and so adding some e2fsck-time warnings seems to be a
better approach IMHO.

						- Ted

  reply	other threads:[~2019-09-03 22:38 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
2019-09-03 21:31     ` Deepa Dinamani
2019-09-03 21:48       ` Arnd Bergmann
2019-09-03 22:38         ` Theodore Y. Ts'o [this message]
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=20190903223815.GH2899@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).