From mboxrd@z Thu Jan  1 00:00:00 1970
From: Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: Finding hardlinks
Date: Wed, 03 Jan 2007 00:14:28 +0100
Message-ID: <1167779668.6090.95.camel@lade.trondhjem.org>
References: <Pine.LNX.4.64.0612200942060.28362@artax.karlin.mff.cuni.cz>
	 <E1GwzsI-0004Y1-00@dorka.pomaz.szeredi.hu>
	 <20061221185850.GA16807@delft.aura.cs.cmu.edu>
	 <Pine.LNX.4.64.0612220038520.4677@artax.karlin.mff.cuni.cz>
	 <1166869106.3281.587.camel@laptopd505.fenrus.org>
	 <Pine.LNX.4.64.0612231458060.5182@artax.karlin.mff.cuni.cz>
	 <4593890C.8030207@panasas.com>
	 <1167300352.3281.4183.camel@laptopd505.fenrus.org>
	 <Pine.LNX.4.64.0612281909200.2960@artax.karlin.mff.cuni.cz>
	 <1167388475.6106.51.camel@lade.trondhjem.org>
	 <Pine.LNX.4.64.0612300154510.19928@artax.karlin.mff.cuni.cz>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Cc: Arjan van de Ven <arjan@infradead.org>,
	Benny Halevy <bhalevy@panasas.com>,
	Jan Harkes <jaharkes@cs.cmu.edu>,
	Miklos Szeredi <miklos@szeredi.hu>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	nfsv4@ietf.org
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from pat.uio.no ([129.240.10.15]:38826 "EHLO pat.uio.no"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S965019AbXABXPB (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
	Tue, 2 Jan 2007 18:15:01 -0500
To: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
In-Reply-To: <Pine.LNX.4.64.0612300154510.19928@artax.karlin.mff.cuni.cz>
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Sat, 2006-12-30 at 02:04 +0100, Mikulas Patocka wrote:
> 
> On Fri, 29 Dec 2006, Trond Myklebust wrote:
> 
> > On Thu, 2006-12-28 at 19:14 +0100, Mikulas Patocka wrote:
> >> Why don't you rip off the support for colliding inode number from the
> >> kernel at all (i.e. remove iget5_locked)?
> >>
> >> It's reasonable to have either no support for colliding ino_t or full
> >> support for that (including syscalls that userspace can use to work with
> >> such filesystem) --- but I don't see any point in having half-way support
> >> in kernel as is right now.
> >
> > What would ino_t have to do with inode numbers? It is only used as a
> > hash table lookup. The inode number is set in the ->getattr() callback.
> 
> The question is: why does the kernel contain iget5 function that looks up 
> according to callback, if the filesystem cannot have more than 64-bit 
> inode identifier?

Huh? The filesystem can have as large a damned identifier as it likes.
NFSv4 uses 128-byte filehandles, for instance.

POSIX filesystems are another matter. They can only have 64-bit
identifiers thanks to the requirement that inode numbers be 64-bit
unique and permanently stored, however Linux caters for a whole
truckload of filesystems which will never fit that label: look at all
those users of iunique(), for one...

Trond