From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Blunck" <jblunck@suse.de>
Subject: Re: [RFC][PATCH 13/14] ext3 whiteout support
Date: Tue, 15 May 2007 10:31:43 +0200
Message-ID: <4de7f8a60705150131s5f357fb1oeae1b5a9251a7c6b@mail.gmail.com>
References: <20070514093722.GB4139@in.ibm.com>
	 <20070514094450.GO4139@in.ibm.com>
	 <1179173817.2836.69.camel@dyn9047017100.beaverton.ibm.com>
	 <20070515062649.GA3465@in.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "Badari Pulavarty" <pbadari@us.ibm.com>,
	lkml <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	"Jan Blunck" <j.blunck@tu-harburg.de>
To: bharata@linux.vnet.ibm.com
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from an-out-0708.google.com ([209.85.132.242]:18631 "EHLO
	an-out-0708.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1756730AbXEOIbs (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Tue, 15 May 2007 04:31:48 -0400
Received: by an-out-0708.google.com with SMTP id d18so492003and
        for <linux-fsdevel@vger.kernel.org>; Tue, 15 May 2007 01:31:47 -0700 (PDT)
In-Reply-To: <20070515062649.GA3465@in.ibm.com>
Content-Disposition: inline
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On 5/15/07, Bharata B Rao <bharata@linux.vnet.ibm.com> wrote:
> On Mon, May 14, 2007 at 01:16:57PM -0700, Badari Pulavarty wrote:
> > On Mon, 2007-05-14 at 15:14 +0530, Bharata B Rao wrote:
> > > From: Bharata B Rao <bharata@linux.vnet.ibm.com>
> > >
> > > +static int ext3_whiteout(struct inode *dir, struct dentry *dentry)
> > > +{
> > > +   struct inode * inode;
> > > +   int err, retries = 0;
> > > +   handle_t *handle;
> > > +
> > > +retry:
> > > +   handle = ext3_journal_start(dir, EXT3_DATA_TRANS_BLOCKS(dir->i_sb) +
> > > +                                   EXT3_INDEX_EXTRA_TRANS_BLOCKS + 3 +
> > > +                                   2*EXT3_QUOTA_INIT_BLOCKS(dir->i_sb));
> > > +   if (IS_ERR(handle))
> > > +           return PTR_ERR(handle);
> > > +
> > > +   if (IS_DIRSYNC(dir))
> > > +           handle->h_sync = 1;
> > > +
> > > +   inode = ext3_new_inode (handle, dir, S_IFWHT | S_IRUGO);
> > > +   err = PTR_ERR(inode);
> > > +   if (IS_ERR(inode))
> > > +           goto out_stop;
> >
> > Don't you need to call init_special_inode() here ?
> > Or this is handled somewhere else ?
>
> Whiteout doesn't have any attributes and hence we are not explicitly
> doing init_special_inode() on this. Accesses to whiteout files are trapped
> at the VFS lookup itself and creation and deletion of whiteouts are handled
> automatically by VFS. So I believe init_special_inode() isn't necessary
> on a whiteout file.
>

I added default whiteout file operations. So calling
init_special_inode() seems to make sense.

I know the ext2/ext3 whiteout patches are not really where they should
be. I plan to use a reserved inode number to reflect the case that the
inode itself doesn't have any attributes itself. It makes sense to
have a singleton whiteout inode per superblock.