On Tue, 7 Jan 2020, Amir Goldstein wrote: > On Tue, Jan 7, 2020 at 2:40 AM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > On Tue, Jan 07, 2020 at 12:16:43AM +0000, Chris Down wrote: > > > Dave Chinner writes: > > > > 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. Interesting take on it. I'd all along imagined we would have to resort to a mount option for safety, but Dave is right that I was too focused on avoiding tmpfs regressions, without properly realizing that people were very unlikely to have written such tools for tmpfs in particular, but written them for all filesystems, and already encountered and fixed such EOVERFLOWs for other filesystems. Hmm, though how readily does XFS actually reach the high inos on ordinary users' systems? > > > > > > > > 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. > > > > > > I'm very glad to hear that. I strongly support moving to 64-bit inums in all > > > cases if there is precedent that it's not a compatibility issue, but from > > > the comments on my original[0] patch (especially that they strayed from the > > > original patches' change to use ino_t directly into slab reuse), I'd been > > > given the impression that it was known to be one. > > > > > > From my perspective I have no evidence that inode32 is needed other than the > > > comment from Jeff above get_next_ino. If that turns out not to be a problem, > > > I am more than happy to just wholesale migrate 64-bit inodes per-sb in > > > tmpfs. > > > > Well, that's my comment above about 32 bit apps using non-LFS > > compliant interfaces in this day and age. It's essentially a legacy > > interface these days, and anyone trying to access a modern linux > > filesystem (btrfs, XFS, ext4, etc) ion 64 bit systems need to handle > > 64 bit inodes because they all can create >32bit inode numbers > > in their default configurations. I thought ext4 still deals in 32-bit inos, so ext4-world would not necessarily have caught up? Though, arguing the other way, IIUC 64-bit ino support comes bundled with file sizes over 2GB (on all architectures?), and it's hard to imagine who gets by with a 2GB file size limit nowadays. > > > > Chris, > > Following Dave's comment, let's keep the config option, but make it > default to Y and remove the mount option for now. > If somebody shouts, mount option could be re-added later. > This way at least we leave an option for workaround for an unlikely > breakage. Though I don't share Dave's strength of aversion to the inode32 and inode64 mount options, I do agree that it's preferable not to offer them if they're so very unlikely to be necessary. Do we even need the config option? We certainly do need to hold the patch with config option and mount options "in our back pocket", so that if a regression does get reported, then upstream and stable can respond to fix it quickly; but do we need more than that? My main concern is that a new EOVERFLOW might not be reported as such, and waste a lot of someone's time to track down. Hugh
