rsync - Sep 2023 - rsync --delete with empty source folder for fast snapshot deletion: Permissions of hardlinked files are changed to 644. Workaround?

So I decided to do a quick test using the Linux kernel source tree since 
it has lots of files.  I duplicated a tree, used 'find . -type f -exec 
chmod 444 {} +' to make read only files for rsync to want to chmod, then 
used cp -al to make several duplicate trees using hard linked files.  An 
rm -rf on one such tree took .97 seconds while an rsync deletion took 
1.25 seconds.  Clearly I need a bigger test to play with as that margin 
could easily change just by different outputs if either had a -v.  But 
also, I did not experience the problem you are describing.  My surviving 
hard links in the duplicate trees were still 444.

BTW, it seems that rsync uses unlink() while rm uses unlinkat().  No 
idea if/why there is a performance diff there but I didn't look into it 
as it is now time for me to go to work.

On 9/22/23 04:14, rsync at altfeld-im.de wrote:
> On Thu, 2023-09-21 at 20:08 -0400, Kevin Korb via rsync wrote:
> 
>> I have heard in the past that rsyncing an empty dir over a tree to
>> delete the tree is faster than an rm -rf but I can't say I have
ever
>> benchmarked it to get any actual numbers.
> 
> This **may** indeed be a myth (for a long time now) re-cited again and
again and
> - could no longer be valid today
> - could apply only when deleting explicitly named files but not deleting
the complete folder
>    (as we need to do in "Back in Time")
> 
> At least I could not find a holistic benchmark with many files and
different scenarios
> (file systems, rsync'ing locally vs. over network, snapshot sizes,
number of files, file sizes, rsync and rm versions...)
> 
> Q: Does `rsync` provide a test case that I could use as basis to prepare
such a holistic benchmark?
> 
>> But now that I am hearing
>> that rsync actually adds a bunch of pointless chmods to the process.?
Is
>> it still faster given this problem?? If so maybe we should be trying to
>> investigate why rm is so slow.
> 
> Just by strace'ing I saw `rm` mainly calls unlink, `rsync` does not.
> 
> 
-- 
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
	Kevin Korb			Phone:    (407) 252-6853
	Systems Administrator		Internet:
	FutureQuest, Inc.		Kevin at FutureQuest.net  (work)
	Orlando, Florida		kmk at sanitarium.net (personal)
	Web page:			https://sanitarium.net/
	PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,

On Fri 22 Sep 2023, Kevin Korb via rsync wrote:
> 444 {} +' to make read only files for rsync to want to chmod, then used
cp
> -al to make several duplicate trees using hard linked files.  An rm -rf on
> one such tree took .97 seconds while an rsync deletion took 1.25 seconds.
Be sure to drop the caches before such tests every time:
echo 3 > /proc/sys/vm/drop_caches


Paul

On Fri, 2023-09-22 at 07:37 -0400, Kevin Korb wrote:
> So I decided to do a quick test using the Linux kernel source tree since 
> it has lots of files.
Excellent idea using kernel sources! A lot of different files...
I will use this to create indicative benchmarks for different scenarios...
> ? I duplicated a tree, used 'find . -type f -exec 
> chmod 444 {} +' to make read only files for rsync to want to chmod,
then
> used cp -al to make several duplicate trees using hard linked files.
> [...]
> But also, I did not experience the problem you are describing.? My
surviving
> hard links in the duplicate trees were still 444.
If attached a script that does the same (with one file instead of the kernel
source tree)
but in my case 444 became 644 again.

- Q: Which rsync version, distro and file system do you use?

- Q: Does my attached script reproduce the permission change?

- Q: Did my script attached to the initial post here reproduce the permission
change?



PS: In my case the attached script shows (excerpt):

./setup_cp_al.sh

Tested with
- rsync  version 3.2.7  protocol version 31
- ext4 file system
- Ubuntu 22.04

File stats BEFORE rsync --delete:

  File: snapshot2/read_only.txt
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 10305h/66309d	Inode: 17571021    Links: 3
Access: (0444/-r--r--r--)  Uid: ( 1000/ user1)   Gid: ( 1000/ user1)
Access: 2023-09-22 20:51:16.690961150 +0200
Modify: 2023-09-22 20:51:16.690961150 +0200
Change: 2023-09-22 20:51:16.694961109 +0200
 Birth: 2023-09-22 20:51:16.690961150 +0200

File stats AFTER rsync --delete

  File: snapshot2/read_only.txt
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 10305h/66309d	Inode: 17571021    Links: 2
Access: (0644/-rw-r--r--)  Uid: ( 1000/ user1)   Gid: ( 1000/ user1)
Access: 2023-09-22 20:51:16.690961150 +0200
Modify: 2023-09-22 20:51:16.690961150 +0200
Change: 2023-09-22 20:51:16.694961109 +0200
 Birth: 2023-09-22 20:51:16.690961150 +0200

Results (after deleting snapshot1 via rsync --delete):
1. The 'Change' time of the hardlinked file was updated
2. The hardlinked file has now different access rights (644 instead of 444 so it
is writable again!)
This does NOT happen if 'rm -f snapshot1/' is used!