On Tue, Jan 07, 2020 at 12:36:25AM -0800, Hugh Dickins wrote: > 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? Quite frequently these days - the threshold for exceeding 32 bits in the inode number is dependent on the inode size. Old v4 filesystems use 256 byte inodes by default, so they overflow 32bits when the filesystem size is >1TB. Current v5 filesystems use 512 byte inodes, so they overflow 32 bits on filesytsems >2TB. > > > > 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? Hmmm - I might have got my wires crossed there - there *was* a project some time ago to increase the ext4 inode number size for large filesystems. Ah, yeah, there we go: https://lore.kernel.org/linux-ext4/20171101212455.47964-1-artem.blagodarenko@xxxxxxxxx/ I thought it had been rolled in with all the other "make stuff larger" features that ext4 has... > 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. Right, you need to define LFS support for >2GB file support and you get 64 bit inode support with that for free. It's only legacy binaries that haven't been rebuilt in the past 15 years that are an issue here, but there are so many other things that can go trivially wrong with such binaries I think that inode numbers are the least of the worries here... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
