4 ms·
Why would running mv before rm be faster? On what file systems is this true?
by edgineer 4y ago
Why would running mv before rm be faster? On what file systems is this true?
- adrianmonk 4y agoThe idea is to rename it so that you don't have to wait for it to be deleted. You can let the deletion run in the background once it has been moved out of the way.
- jeffrallen 4y agoAnd to be totally, ridiculously pedantic (this is HN after all) mv is a single atomic metadata operation in the filesystem, which will almost certainly go into the filesystem log without any wait on i/o. A big rm is going to generate enough metadata churn that the filesystem log will need to be synced to hardware at least once, and then you've got 2 or 3 orders of magnitude more time to wait (per sync).
- aix1 4y agoPlus, if there's a complex directory tree, rm has to traverse it (to deal with all the metadata) while mv doesn't.
- jeffreygoesto 4y agoIt's not faster, just somewhere else.
- WJW 4y agoI think you missed the `&` at the end of the rm command, which runs it as a background process. It's not faster in total time, but it will allow the user to continue inputting new commands much sooner.