Hi! On Tue 07-06-16 09:59:58, Bob Peterson wrote: > 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? 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 -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- 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
