From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH 1/2] handling 64bit values for st_ino] Date: Thu, 10 Nov 2005 14:04:19 +0000 Message-ID: <20051110140419.GF7992@ftp.linux.org.uk> References: <20051110003024.GD7992@ftp.linux.org.uk> <437343B1.5000809@redhat.com> <20051110134336.GE7992@ftp.linux.org.uk> <4373508F.9060004@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:22713 "EHLO ZenIV.linux.org.uk") by vger.kernel.org with ESMTP id S1750921AbVKJOET (ORCPT ); Thu, 10 Nov 2005 09:04:19 -0500 To: Peter Staubach Content-Disposition: inline In-Reply-To: <4373508F.9060004@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Nov 10, 2005 at 08:52:15AM -0500, Peter Staubach wrote: > Two different sized types to describe inode numbers, different paths, etc. > Having two of something, when just one would suffice, is usually more > complicated. _What_ different paths? And what "two of something"? The only requirement for fs that want to report wider st_ino is to put the right value into kstat->ino in their ->getattr(). And there's already a plenty of filesystems using iget5() et.al. for icache lookups - this isn't adding anything new. As far as 64bit ino_t is concerned - no, thanks. We'd need to walk through all existing fs code and audit existing uses of ino_t. Which is far more of support burden. And then there's an issue of overhead on normal icache lookups for nearly all existing filesystems; ones that do wider lookup keys are *already* using iget5(), BTW. So you'll simply punish all users of iget().