Date: Thu, 16 Jun 2016 20:00:33 +0200
From: Jan Kara <jack@suse.cz>
To: Bob Peterson <rpeterso@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, Alexander Viro <aviro@redhat.com>
Subject: Re: Shouldn't iget_locked be using u64 rather than unsigned long ino?
Message-ID: <20160616180033.GC2106@quack2.suse.cz>
References: <501706658.15613331.1465307227820.JavaMail.zimbra@redhat.com>
 <52112125.15651374.1465307998068.JavaMail.zimbra@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52112125.15651374.1465307998068.JavaMail.zimbra@redhat.com>
Sender: linux-fsdevel-owner@vger.kernel.org

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