[Cluster-devel] [RFC 3/3] GFS2 rename race - core changes

[Cluster-devel] [RFC 3/3] GFS2 rename race - core changes

[Wendy Cheng]

Upon failure of gfs2_unlink_ok(), we discard the old dentry, create a 
new dentry, and then fill in the correct inode contents. This is to 
avoid gfs_rename() returns ENOENT for destination file changes.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: gfs2_rename_core.patch
Type: text/x-patch
Size: 6257 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/cluster-devel/attachments/20061212/0dd5e077/attachment.bin>

[Cluster-devel] [RFC 3/3] GFS2 rename race - core changes

[Steven Whitehouse]

Hi,

On Tue, 2006-12-12 at 03:19 -0500, Wendy Cheng wrote:
> Upon failure of gfs2_unlink_ok(), we discard the old dentry, create a 
> new dentry, and then fill in the correct inode contents. This is to 
> avoid gfs_rename() returns ENOENT for destination file changes.
> 
> 

I think that you might have to look at the set/reset of
FS_RENAME_DOES_D_MOVE again. This flag is intended to be constant and
set as part of the struct file_system_type. Also it needs to be set on
both of the filesystem types since its required on the metafs as well.

I think its a better plan for GFS2 to do the d_move in all cases to
avoid the races which are otherwise introduced by trying to change the
flag. Otherwise I think the patch looks good,

Steve.