Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Mikael Magnusson <mikachu@gmail.com>
To:     david@fromorbit.com
Cc:     akpm@linux-foundation.org, amir73il@gmail.com,
        chris@chrisdown.name, hannes@cmpxchg.org, hughd@google.com,
        jlayton@kernel.org, kernel-team@fb.com,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org, tj@kernel.org, viro@zeniv.linux.org
Subject: Re: [PATCH v5 2/2] tmpfs: Support 64-bit inums per-sb
Date:   Wed,  8 Jan 2020 15:37:52 +0100
Message-Id: <20200108143752.9475-1-mikachu@gmail.com>
In-Reply-To: <20200107001039.GM23195@dread.disaster.area>
References: <20200107001039.GM23195@dread.disaster.area>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Dave Chinner writes:
> On Sun, Jan 05, 2020 at 12:06:05PM +0000, Chris Down wrote:
> > The default is still set to inode32 for backwards compatibility, but
> > system administrators can opt in to the new 64-bit inode numbers by
> > either:
> > 
> > 1. Passing inode64 on the command line when mounting, or
> > 2. Configuring the kernel with CONFIG_TMPFS_INODE64=y
> > 
> > The inode64 and inode32 names are used based on existing precedent from
> > XFS.
> 
> Please don't copy this misfeature of XFS.
> 
> The inode32/inode64 XFS options were a horrible hack made more than
> 20 years ago when NFSv2 was still in use and 64 bit inodes could
> not be used for NFSv2 exports. It was then continued to be used
> because 32bit NFSv3 clients were unable to handle 64 bit inodes.
> 
> It took 15 years for us to be able to essentially deprecate
> inode32 (inode64 is the default behaviour), and we were very happy
> to get that albatross off our necks.  In reality, almost everything
> out there in the world handles 64 bit inodes correctly
> including 32 bit machines and 32bit binaries on 64 bit machines.
> And, IMNSHO, there no excuse these days for 32 bit binaries that
> don't using the *64() syscall variants directly and hence support
> 64 bit inodes correctlyi out of the box on all platforms.
> 
> I don't think we should be repeating past mistakes by trying to
> cater for broken 32 bit applications on 64 bit machines in this day
> and age.

Hi,

It's unfortunately not true that everything handles this correctly.
32-bit binaries for games on Steam that use stat() without the 64 is
so prevalent that I got tired of adding the LD_PRELOAD wrapper script
and just patched out the EOVERFLOW return from glibc instead. (They
obviously don't care about the inode value at all, and I don't use any
other 32-bit binaries that do). This is probably a class of binaries
you don't care very much about, and not very likely to be installed on
a tmpfs that has wrapped around, but I thought it was worth mentioning
that they do exist anyway.

-- 
Mikael Magnusson