On Wed, Sep 29, 2010 at 04:19:31PM -0400, Oren Laadan wrote: > > > On 09/23/2010 05:53 PM, Matt Helsley wrote: > >Not all filesystems will necessarily be able to support relinking an > >orphan inode back into the filesystem. Some offlist feedback suggested > >that instead of overloading .link that relinking should be a separate > >file operation for this reason. > > > >Since .relink is a superset of .link make the VFS call .relink where > >possible and .link otherwise. > > > >The next commit will change ext3/4 to enable this operation. > > > >Signed-off-by: Matt Helsley<matthltc@xxxxxxxxxx> > >Cc: Theodore Ts'o<tytso@xxxxxxx> > >Cc: Andreas Dilger<adilger.kernel@xxxxxxxxx> > >Cc: Jan Kara<jack@xxxxxxx> > >Cc: linux-fsdevel@xxxxxxxxxxxxxxx > >Cc: linux-ext4@xxxxxxxxxxxxxxx > >Cc: Al Viro<viro@xxxxxxxxxxxxxxxxxx> > >--- > > fs/namei.c | 5 ++++- > > include/linux/fs.h | 1 + > > 2 files changed, 5 insertions(+), 1 deletions(-) > > > >diff --git a/fs/namei.c b/fs/namei.c > >index a7dce91..eb279e3 100644 > >--- a/fs/namei.c > >+++ b/fs/namei.c > >@@ -2446,7 +2446,10 @@ int vfs_link(struct dentry *old_dentry, struct inode *dir, struct dentry *new_de > > return error; > > > > mutex_lock(&inode->i_mutex); > >- error = dir->i_op->link(old_dentry, dir, new_dentry); > >+ if (dir->i_op->relink) > >+ error = dir->i_op->relink(old_dentry, dir, new_dentry); > >+ else > >+ error = dir->i_op->link(old_dentry, dir, new_dentry); > > Can there be a scenario/filesystem in which .relink implementation > is so much more complex (and expensive) than .link ? > > If the answer is "yes", then this we probably don't want to do > this, and let vfs_link() call .link, and instead add a new helper > vfs_relink(). OK, that makes some sense too. I thought the separation would just be at the file operations layer but we can move it higher too. I'll adjust the patches to do that and repost them. Cheers, -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
