Here's GNU coreutils rm [0] calling its remove() function [1] itself using fts to open, traverse, and remove each entry[2], vs rsync delete() [3] calling {{robust,do}_,}unlink() function [4] [5].
Now a little profiling could certainly help.
(damn gitweb that doesn't highlight the referenced line)
Thanks. Was on a phone last night and wasn't able to find the sources easily. But there's still a lot of unknowns in the article to try to repro.
So one thing that's interesting is that both rsync and rm stat every file in each directory to determine whether to use rmdir or unlink, and to perform a depth first removal. I wonder if it would be faster to skip the stats, just call unlink on everthing and check errno for EISDIR (not POSIX, but returned by Linux), then descend as needed and use rmdir on the way back up.
Here's GNU coreutils rm [0] calling its remove() function [1] itself using fts to open, traverse, and remove each entry[2], vs rsync delete() [3] calling {{robust,do}_,}unlink() function [4] [5].
Now a little profiling could certainly help.
(damn gitweb that doesn't highlight the referenced line)
[0]: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f...
[1]: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f...
[2]: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f...
[3]: http://rsync.samba.org/ftp/unpacked/rsync/delete.c
[4]: http://rsync.samba.org/ftp/unpacked/rsync/util.c
[5]: http://rsync.samba.org/ftp/unpacked/rsync/syscall.c