All of lore.kernel.org
 help / color / mirror / Atom feed
From: Deepa Dinamani <deepa.kernel@gmail.com>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Arnd Bergmann <arnd@arndb.de>, 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: Wed, 4 Sep 2019 07:25:19 -0700	[thread overview]
Message-ID: <CABeXuvoKE4VrnAcHff+veyds+JbqzrUtYxBJ4tUv3eaUsec0bw@mail.gmail.com> (raw)
In-Reply-To: <20190904125834.GA3044@mit.edu>

> On Sep 4, 2019, at 5:58 AM, Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
>> On Tue, Sep 03, 2019 at 09:50:09PM -0700, Deepa Dinamani wrote:
>> If we don't care to warn about the timestamps that are clamped in
>> memory, maybe we could just warn when they are being written out.
>> Would something like this be more acceptable? I would also remove the
>> warning in ext4.h. I think we don't have to check if the inode is 128
>> bytes here (Please correct me if I am wrong). If this looks ok, I can
>> post this.
>
> That's better, but it's going to be misleading in many cases.  The
> inode's extra size field is 16 or larger, there will be enough space
> for the timestamps, so talking about "timestamps on this inode beyond
> 2038" when ext4 is unable to expand it from say, 24 to 32, won't be
> true.  Certain certain features won't be available, yes --- such as
> project-id-based quotas, since there won't be room to store the
> project ID.  However, it's not going to impact the ability to store
> timestamps beyond 2038.  The i_extra_isize field is not just about
> timestamps!

I understand that i_extra_isize is not just about timestamps. It’s
evident from EXT4_FITS_IN_INODE(). I think we can check for
EXT4_FITS_IN_INODE() here if that will consistently eliminates false
positives.

But, I hear you. You think this warning is unnecessary. I think there
are many file systems and I don’t think anybody would knows in’s and
outs of each one. I think if I’m mounting an ext4 fs and it has mixed
sizes of inodes, I think I would at least expect a dmesg(with a hint
on how to fix it) considering that this filesystem is restricted in
more ways than just time. Is this the purpose of the warning you
already have?:

        if (error && (mnt_count != le16_to_cpu(sbi->s_es->s_mnt_count))) {
               ext4_warning(inode->i_sb, "Unable to expand inode %lu.
Delete some EAs or run e2fsck.",

Maybe there should be a warning, but it has nothing to do with just
time. Do we already have this?

-Deepa

  parent reply	other threads:[~2019-09-04 14:25 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
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 [this message]
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=CABeXuvoKE4VrnAcHff+veyds+JbqzrUtYxBJ4tUv3eaUsec0bw@mail.gmail.com \
    --to=deepa.kernel@gmail.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=arnd@arndb.de \
    --cc=cai@lca.pw \
    --cc=jlayton@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.