On 5/15/07, Bharata B Rao <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > > > +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. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
