Shouldn't iget_locked be using u64 rather than unsigned long ino?

Shouldn't iget_locked be using u64 rather than unsigned long ino?

[Bob Peterson]

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

Re: Shouldn't iget_locked be using u64 rather than unsigned long ino?

[Jan Kara]

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@suse.com>
SUSE Labs, CR