I recently found myself performing data recovery on an external SSD that had its APFS-volume corrupted by a bad USB-hub built into a monitor. Initiating the recovery, I checked "Save all files to one folder" (mistakenly believing this would retain the source folder hierarchy, but using a custom root directory for recovery) - ending up with a flat folder structure full of about 3,5 million files. The only drive available to me at the time that was big enough to act as a recovery target was an external HDD. This left me in a bind, as USB HDD disk access is obviously slow, and removing such a huge amount of files in a naive fashion is extremely slow. Not being able to just format the recovery disk (because of its other contents), I ended up experimenting with various speed-up strategies.
I write this blogpost in case someone else should be as unfortunate and end up in a similar situation.
After experimenting with rm, rsync-ing with an empty directory, and distributing the rm-ing of the folder's contents over several threads using xargs, I ended up with the following strategy using [GNU parallel](https://www.gnu.org/software/parallel/):
#/usr/bin/env bash
cd $FOLDER_WITH_TONS_OF_FILES
# Count the files in the folder, and show its size on disk
\ls -afq "$(pwd)" | wc -l
du -sh "$(pwd)"
# Parallelize file deletion to max extent possible, printing the name of every file once deleted
find . -print0 | parallel -0 -j 0 rm -rf -v;In my case, this deletion took several days...