From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: fishy ->put_inode usage in ntfs Date: Thu, 10 Feb 2005 11:47:19 +0100 Message-ID: <20050210104719.GA2771@lst.de> References: <20041014112607.GA24508@lst.de> <1097757569.21275.40.camel@imp.csi.cam.ac.uk> <20041014125933.GA26021@lst.de> <1097760404.21275.52.camel@imp.csi.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ntfs-dev , linux-fsdevel@vger.kernel.org Received: from verein.lst.de ([213.95.11.210]:31185 "EHLO mail.lst.de") by vger.kernel.org with ESMTP id S262095AbVBJKr2 (ORCPT ); Thu, 10 Feb 2005 05:47:28 -0500 To: Anton Altaparmakov Content-Disposition: inline In-Reply-To: <1097760404.21275.52.camel@imp.csi.cam.ac.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Oct 14, 2004 at 02:26:45PM +0100, Anton Altaparmakov wrote: > > I don't like filesystem doings things like this in ->put_inode at all, > > and indeed the plan is to get rid of ->put_inode completely. Why do > > you need to hold an additional reference anyway? What's so special > > about the relation of these two inodes? > > The bmp_ino is a virtual inode. It doesn't exist on disk as an inode. > It is an NTFS attribute of the base inode. It cannot exist without the > base inode there. You could neither read from nor write to this inode > without its base inode being there and you couldn't even clear_inode() > this inode without the base inode being there. The reference is > essential I am afraid. > > If ->put_inode is removed then I will have to switch to using > ntfs_attr_iget() each time or I will have to attach the inode in some > other much hackier way that doesn't use the i_count and uses my ntfs > private counter instead. Coming back to this issue. Why do you need to refcount bmp_ino at all? Can someone ever grab a reference separate from it's master inode?