kernel@kvack.org writes:
> LFS doesn't require that ino64_t be 64 bits. Even so, the stat64
> structure has enough space for us to put a 64 bit inode number in
> (__unused[12]). That leaves the compatibility problem that going
> to a 64 bit ino_t raises: all of the old stat routines would have
> to be deprecated and removed from the kernel since there is no
> reasonable way to map a 64 bit inode number into an old stat
> structure. Now is not the time to create that mess.
Now is the perfect time to create that mess. The sooner the better!
If 32-bit inode numbers are good enough for your filesystem today,
then you won't care if userspace chops a 64-bit inode number down
to 32 bits. Switching over now would prepare us for having better
filesystem support in the future.
So, we are having problems with NFSv3, Reiserfs, UDF, NTFS, XFS...
But did anybody listen to me? Noooo.... I told you so!
Oh, make the generation number 64-bit too. That way, a 128-bit AFS
or Coda file ID can be sanely stuffed into struct stat. Might as
well add VFS flags (mountpoint, has-ACL, read-only...) now too.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:22 EST