Skip to content

Comment on A faster way to delete millions of files in a directory

Comments

It's sad to see so much guesswork around here...

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

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.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.