Re: [PATCH v5 2/2] tmpfs: Support 64-bit inums per-sb

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

0: https://lore.kernel.org/patchwork/patch/1170963/




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux