public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/2] Add support to RENAME_EXCHANGE flag to XFS V8
@ 2014-11-25 13:49 Carlos Maiolino
  2014-11-25 13:49 ` [PATCH 1/2] Make xfs_vn_rename compliant with renameat2() syscall Carlos Maiolino
  2014-11-25 13:49 ` [PATCH 2/2] Add support to RENAME_EXCHANGE flag V8 Carlos Maiolino
  0 siblings, 2 replies; 8+ messages in thread
From: Carlos Maiolino @ 2014-11-25 13:49 UTC (permalink / raw)
  To: xfs

This patchset aims to implement RENAME_EXCHANGE support (from sys_renameat2) to
XFS.

For this to be achieved, XFS need to export a rename2() method, which I included
in the first patch.

The second patch is the real implementation of the RENAME_EXCHANGE flags, which
most of the work I based on xfs_rename().

This patchset passed the xfstests 23, 24 and 25 (specifically for 
RENAME_EXCHANGE), and I also tested the projectID inheritance problem, where
both paths must be under the same projectID to be able to change (I'm going to
implement this test into the xfstests too).

In this version of the patch, I tried to use xfs_rename for everything in
common between a usual rename and the RENAME_EXCHANGE, using xfs_cross_rename()
just for the needed stuff to accomplish RENAME_EXCHANGE requirements (as 
suggested by Brian).

Also, this new version contains a fix to ensure both files will have their
i_mode updated, so that d_type object (in superblock V5) will contain the proper
information after the exchange happens

Refer to specific patch descriptions for more information regarding new patch
versions

Carlos Maiolino (2):
  Make xfs_vn_rename compliant with renameat2() syscall
  Add support to RENAME_EXCHANGE flag V8

 fs/xfs/xfs_inode.c | 112 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
 fs/xfs/xfs_inode.h |   2 +-
 fs/xfs/xfs_iops.c  |  24 +++++++++---
 3 files changed, 130 insertions(+), 8 deletions(-)

-- 
2.1.0

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] Add support to RENAME_EXCHANGE flag V8
@ 2014-12-02 14:13 Carlos Maiolino
  2014-12-02 14:15 ` Carlos Maiolino
  2014-12-02 21:43 ` Dave Chinner
  0 siblings, 2 replies; 8+ messages in thread
From: Carlos Maiolino @ 2014-12-02 14:13 UTC (permalink / raw)
  To: xfs

Hi Dave,


>> +			error = xfs_dir_replace(tp, ip2, &xfs_name_dotdot,
>> +						dp1->i_ino, first_block,
>> +						free_list, spaceres);
>> +			if (error)
>> +				goto out;

>now ip2 is modified, so it ctime/mtime dirty.

>> +
>> +			/* transfer target ".." reference to dp1 */
>> +			if (!S_ISDIR(ip1->i_d.di_mode)) {
>> +				error = xfs_droplink(tp, dp2);
>> +				if (error)
>> +					goto out;
>> +				error = xfs_bumplink(tp, dp1);
>> +				if (error)
>> +					goto out;
>> +			}
>> +			xfs_trans_ichgtime(tp, ip1, XFS_ICHGTIME_CHG);
>> +			xfs_trans_ichgtime(tp, ip2,
>> +					   XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG);
>> +			xfs_trans_log_inode(tp, ip2, XFS_ILOG_CORE);

>But now you're unconditionally changing ctime on ip1 without it
>having been modified and you aren't logging the change. Why is the
>ctime changing (comments, please!)?

Ok, so, I can see that I didn't understand what we should do with logging here,
for the moment, I thought we should bump the ip1 to notify userspace that
changes has actually taken place here, even though we are not changing it
anyway. I'm not sure if I should log it too (and add a xfs_trans_log_inode for
ip1). So, should we also log it here together with ip1, or bumping ctime of ip1
here is wrong?
In this case, a more correct way to write it would be to not bump ip1 here but
only in the next block, where we actually touches it?
And regarding dp2 and dp1, we drop/bump its link counts here, should I care
about logging them in this code block? My xfs logging knowledge is shallow by
now :-(

>> +		}
>> +
>> +		if (S_ISDIR(ip1->i_d.di_mode)) {
>> +			error = xfs_dir_replace(tp, ip1, &xfs_name_dotdot,
>> +						dp2->i_ino, first_block,
>> +						free_list, spaceres);
>> +			if (error)
>> +				goto out;

>here ip2 is modified

>> +
>> +			/* transfer src ".." reference to dp2 */
>> +			if (!S_ISDIR(ip2->i_d.di_mode)) {
>> +				error = xfs_droplink(tp, dp1);
>> +				if (error)
>> +					goto out;
>> +				error = xfs_bumplink(tp, dp2);
>> +				if (error)
>> +					goto out;
>> +			}
>> +			xfs_trans_ichgtime(tp, ip1,
>> +					   XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG);
>> +			xfs_trans_ichgtime(tp, ip2, XFS_ICHGTIME_CHG);
>> +			xfs_trans_log_inode(tp, ip1, XFS_ILOG_CORE);

>and same again - changing ctime on ip2 without logging it.

>> +		}
>> +		xfs_trans_ichgtime(tp, dp2,
>> +				   XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG);
>> +		xfs_trans_log_inode(tp, dp2, XFS_ILOG_CORE);
>> +	}
>> +	xfs_trans_ichgtime(tp, dp1, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG);
>> +	xfs_trans_log_inode(tp, dp1, XFS_ILOG_CORE);

>perhaps:

>	int	ip1_flags = 0;
>	int	ip2_flags = 0;
>	int	dp2_flags = 0;
>
>	if (dp1 != dp2)
>		dp2_flags = XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG;
>
>		if (S_ISDIR(ip1)) {
>			ip1_flags |= XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG;
>			ip2_flags |= XFS_ICHGTIME_CHG; /* because ... */
>			.....
>		}
>
>		if (S_ISDIR(ip2)) {
>			ip1_flags |= XFS_ICHGTIME_CHG; /* because ... */
>			ip2_flags |= XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG;
>			.....
>		}
>	}
>
>	if (ip1_flags) {
>		xfs_trans_ichgtime(tp, ip1, ip1_flags);
>		xfs_trans_log_inode(tp, ip1);
>	}
>	if (ip2_flags) {
>		xfs_trans_ichgtime(tp, ip2, ip2_flags);
>		xfs_trans_log_inode(tp, ip2);
>	}
>	if (dp2_flags) {
>		xfs_trans_ichgtime(tp, dp2, ip2_flags);
>		xfs_trans_log_inode(tp, dp2);
>	}
>	xfs_trans_ichgtime(tp, dp2, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG);
>	xfs_trans_log_inode(tp, dp2);

I don't think that these extra variables will actually clear the code and make
it more readable IMHO, calling xfs_trans_ichgtime with the flags directly looks
more clear and readable to me.

Thanks for the review,
I have fixed all the another points you mentioned now, I think that handling log
correct on the above snippet is the last thing to do by now.

cheers.

-- 
Carlos

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2014-12-02 21:44 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-11-25 13:49 [PATCH 0/2] Add support to RENAME_EXCHANGE flag to XFS V8 Carlos Maiolino
2014-11-25 13:49 ` [PATCH 1/2] Make xfs_vn_rename compliant with renameat2() syscall Carlos Maiolino
2014-11-25 13:49 ` [PATCH 2/2] Add support to RENAME_EXCHANGE flag V8 Carlos Maiolino
2014-11-25 13:51   ` Carlos Maiolino
2014-11-28  1:38   ` Dave Chinner
  -- strict thread matches above, loose matches on Subject: below --
2014-12-02 14:13 Carlos Maiolino
2014-12-02 14:15 ` Carlos Maiolino
2014-12-02 21:43 ` Dave Chinner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox