linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Down <chris@chrisdown.name>
To: Hugh Dickins <hughd@google.com>, Dave Chinner <david@fromorbit.com>
Cc: Chris Mason <clm@fb.com>, Amir Goldstein <amir73il@gmail.com>,
	Linux MM <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Matthew Wilcox <willy@infradead.org>,
	Jeff Layton <jlayton@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>, Tejun Heo <tj@kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH v5 2/2] tmpfs: Support 64-bit inums per-sb
Date: Fri, 10 Jan 2020 16:45:03 +0000	[thread overview]
Message-ID: <20200110164503.GA1697@chrisdown.name> (raw)
In-Reply-To: <alpine.LSU.2.11.2001080259350.1884@eggly.anvils>

Hi Hugh, Dave,

Hugh Dickins writes:
>Dave, Amir, Chris, many thanks for the info you've filled in -
>and absolutely no need to run any scan on your fleet for this,
>I think we can be confident that even if fb had some 15-year-old tool
>in use on its fleet of 2GB-file filesystems, it would not be the one
>to insist on a kernel revert of 64-bit tmpfs inos.
>
>The picture looks clear now: while ChrisD does need to hold on to his
>config option and inode32/inode64 mount option patch, it is much better
>left out of the kernel until (very unlikely) proved necessary.

Based on Mikael's comment above about Steam binaries, and the lack of 
likelihood that they can be rebuilt, I'm inclined to still keep inode{64,32}, 
but make legacy behaviour require explicit opt-in. That is:

- Default it to inode64
- Remove the Kconfig option
- Only print it as an option if tmpfs was explicitly mounted with inode32

The reason I suggest keeping this is that I'm mildly concerned that the kind of 
users who might be impacted by this change due to 32-bit _FILE_OFFSET_BITS -- 
like the not-too-uncommon case that Mikael brings up -- seem unlikely to be the 
kind of people that would find it in an rc.

Other than that, the first patch could be similar to how it is now, 
incorporating Hugh's improvements to the first patch to put everything under 
the same stat_lock in shmem_reserve_inode.

What do you folks think?

Thanks,

Chris

  parent reply	other threads:[~2020-01-10 16:45 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-05 12:05 [PATCH v5 0/2] fs: inode: shmem: Reduce risk of inum overflow Chris Down
2020-01-05 12:06 ` [PATCH v5 1/2] tmpfs: Add per-superblock i_ino support Chris Down
2020-01-06  2:03   ` zhengbin (A)
2020-01-06  6:41     ` Amir Goldstein
2020-01-07  8:01       ` Hugh Dickins
2020-01-07  8:35         ` Amir Goldstein
2020-01-08 10:58           ` Hugh Dickins
2020-01-08 12:51             ` Amir Goldstein
2020-01-06 13:17     ` Chris Down
2020-01-05 12:06 ` [PATCH v5 2/2] tmpfs: Support 64-bit inums per-sb Chris Down
2020-01-07  0:10   ` Dave Chinner
2020-01-07  0:16     ` Chris Down
2020-01-07  0:39       ` Dave Chinner
2020-01-07  6:54         ` Amir Goldstein
2020-01-07  8:36           ` Hugh Dickins
2020-01-07 10:12             ` Amir Goldstein
2020-01-07 21:07               ` Dave Chinner
2020-01-07 21:37                 ` Chris Mason
2020-01-08 11:24                   ` Hugh Dickins
2020-01-09  0:43                     ` Jeff Layton
2020-01-10 16:45                     ` Chris Down [this message]
2020-01-13  7:36                       ` Hugh Dickins
2020-01-20 15:11                         ` Chris Down
2020-02-25 23:14                           ` Hugh Dickins
2020-01-07 20:59             ` Dave Chinner
2020-01-08 14:37     ` Mikael Magnusson
2020-01-13  6:58       ` Hugh Dickins

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=20200110164503.GA1697@chrisdown.name \
    --to=chris@chrisdown.name \
    --cc=Kernel-team@fb.com \
    --cc=akpm@linux-foundation.org \
    --cc=amir73il@gmail.com \
    --cc=clm@fb.com \
    --cc=david@fromorbit.com \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tj@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    /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).