Live data from Hacker News

The fastest rm command and one of the fastest cp commands

alexsaveau.dev

1–10 of 83 posts

Re: The fastest rm command and one of the fastest cp commands

#3
I cant wait to see the future where we have uring (io_uring) based tools that all work async, getting hopefully embarassingly parallel. Heck yes copying & deleting 2x as fast.

Actually I'm on btrfs so reflink copy is like instant I think? I should test that better.

Re: The fastest rm command and one of the fastest cp commands

#8

If you need a large sub tree gone, mv dir .old-dir && rm -r .old-dir & works pretty well. Faster even than an optimized parallel unlinker.

Probably good enough for most use cases, and it’s basically what I do when I’m sure it’ll succeed. And a lot of times I just do the mv and worry about cleanup later, because disk space is cheaper than recreating whatever I might yeet by mistake.

Re: The fastest rm command and one of the fastest cp commands

#9

If you need a large sub tree gone, mv dir .old-dir && rm -r .old-dir & works pretty well. Faster even than an optimized parallel unlinker.

That’s pretty outside-the-box and fun.

Amusingly it’s basically how most GUI desktops “delete” stuff, they just put a confirmation in place of the &&

Re: The fastest rm command and one of the fastest cp commands

#10
Hmm. I appreciate the cute name for the project but I tested this on my machine (a Mac) and the results were not very impressive. I sacrificed a few of my SSD cycles to test how this is on deleting Xcode (for those unaware, it's a 11 GB mess of several hundred thousand files of varying sizes). Here are the results:

  $ time rm -rf Xcode.app
  
  real 0m39.850s
  user 0m0.429s
  sys 0m29.153s
  
  $ time rmz Xcode.app
  
  real 0m36.476s
  user 0m1.468s
  sys 1m59.916s
It's a little bit faster, but not by much. Despite claims that it runs in parallel, it seems like it really just hits unlink on many more cores and contends on the kernel's filesystem spinlocks rather than doing useful work. So the end result is that rm uses 70% CPU and rmz uses 400% CPU and they basically end up doing the same thing.

(FWIW, I don't use rm when deleting Xcode anyways, because it takes long and I do it too often. When testing unxip I just have it write to a temporary APFS volume and wipe it in between runs, which takes all of 10 seconds.)

Post reply on HN