On Wednesday 03 January 2007 21:26, Frank van Maarseveen wrote: > On Wed, Jan 03, 2007 at 08:31:32PM +0100, Mikulas Patocka wrote: > > 64-bit inode numbers space is not yet implemented on Linux --- the problem > > is that if you return ino >= 2^32, programs compiled without > > -D_FILE_OFFSET_BITS=64 will fail with stat() returning -EOVERFLOW --- this > > failure is specified in POSIX, but not very useful. > > hmm, checking iunique(), ino_t, __kernel_ino_t... I see. Pity. So at > some point in time we may need a sort of "ino64" mount option to be > able to switch to a 64 bit number space on mount basis. Or (conversely) > refuse to mount without that option if we know there are >32 bit st_ino > out there. And invent iunique64() and use that when "ino64" specified > for FAT/SMB/... when those filesystems haven't been replaced by a > successor by that time. > > At that time probably all programs are either compiled with > -D_FILE_OFFSET_BITS=64 (most already are because of files bigger than 2G) > or completely 64 bit. Good plan. Be prepared to redo it again when 64bits will feel "small" also. Then again when 128bit will be "small". Don't tell me this won't happen. 15 years ago people would laugh about 32bit inode numbers being not enough. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
