Currently, large file support is already necessary to handle dvd and video. It's also useful for images for virtualization. So the failing stat() calls should already be a thing of the past with modern distributions.As long as glibc compiles by default with 32-bit ino_t, the problem exists and is severe --- programs handling large files, such as coreutils, tar, mc, mplayer, already compile with 64-bit ino_t and off_t, but the user (or script) may type something like: cat >file.c <<EOF #include <sys/types.h> #include <sys/stat.h> main() { int h; struct stat st; if ((h = creat("foo", 0600)) < 0) perror("creat"), exit(1); if (fstat(h, &st)) perror("stat"), exit(1); close(h); return 0; } EOF gcc file.c; ./a.out --- and you certainly do not want this to fail (unless you are out of disk space). The difference is, that with 32-bit program and 64-bit off_t, you get deterministic failure on large files, with 32-bit program and 64-bit ino_t, you get random failures.What's (technically) the problem with changing the gcc default?
Technically none (i.e. edit gcc specs or glibc includes). But persuading all distribution builders to use this version is impossible. Plus there are many binary programs that are unchangable.
Alternatively we could make the error deterministic in various ways. Start st_ino numbering from 4G (except for a few special ones maybe such as root/mounts). Or make old and new programs look differently at the ELF level or by sys_personality() and/or check against a "ino64" mount flag/filesystem feature. Lots of possibilities.
I think the best solution would be to drop -EOVERFLOW on st_ino and let legacy 32-bit programs live with coliding inodes. They'll have anyway.
Mikulas - 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
