From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: Finding hardlinks Date: Fri, 29 Dec 2006 11:34:35 +0100 Message-ID: <1167388475.6106.51.camel@lade.trondhjem.org> References: <20061221185850.GA16807@delft.aura.cs.cmu.edu> <1166869106.3281.587.camel@laptopd505.fenrus.org> <4593890C.8030207@panasas.com> <1167300352.3281.4183.camel@laptopd505.fenrus.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Jan Harkes , Miklos Szeredi , linux-kernel@vger.kernel.org, nfsv4@ietf.org, linux-fsdevel@vger.kernel.org, Benny Halevy , Arjan van de Ven Return-path: To: Mikulas Patocka In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org List-Id: linux-fsdevel.vger.kernel.org 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. Cheers Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4