Shouldn't iget_locked be using u64 rather than unsigned long ino?
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi,
For a while now, I've been annoyed by the fact that function iget_locked and friends (test_inode_iunique, find_inode_fast, ilookup, etc.) use "unsigned long ino" rather than u64 for inode number. File systems need to be consistent across multiple architectures, and 32-bits is hardly adequate for modern storage. This can only result in problems and/or unnecessary restrictions for file systems with block-number based inode numbers like gfs2, and/or force them to kludge around it to prevent problems in mixed architectures. (Not that anyone is likely to use GFS2 on a 32-bit arch, but still.) Opinions?
Regards,
Bob Peterson
Red Hat File Systems
Jan Kara
reviewerHi!
Quoted 8 lines · Bob Peterson
For a while now, I've been annoyed by the fact that function
iget_lockedand friends (test_inode_iunique,find_inode_fast, ilookup, etc.) use "unsigned long ino" rather than u64 for inode number. File systems need to be consistent across multiple architectures, and 32-bits is hardly adequate for modern storage. This can only result in problems and/or unnecessary restrictions for file systems with block-number based inode numbers like gfs2, and/or force them to kludge around it to prevent problems in mixed architectures. (Not that anyone is likely to use GFS2 on a 32-bit arch, but still.) Opinions?
Well, if you look at struct inode, you'll see that i_ino is unsigned long there as well. So changing the inode number to u64 would have to be a wider reaching change than iget_locked() and friends. Frankly, if you want to do anything about the type of i_ino, I'd be for declaring a type for it (like ino_t). Then we could treat it similarly as sector_t and define it as u64 if special config option is set (for sector_t it is called CONFIG_LBDAF) and otherwise keep it as unsigned long.
Honza
Signature · 2 lines
Jan Kara <[email protected]> SUSE Labs, CR