Even faster:
mkdir ../.tmp${RANDOM} && mv ./* ../.tmp[0-9]* && rm -rf ../.tmp[0-9]* & #or the rsync trick
As long as ../ is on the same device, that should clear the directory instantaneously. It is the point, right? Of course, if you want an rm for lower IO-wait or lower CPU, use the rsync method, but if you want something that clear a directory as fast as possible, this is fast. Tested with
for I in `seq 1 1000000`; do echo ${I} > ./${I};done;sync
#^ much faster than "touch"
A) You're cheating by using the tmpfs filesystem!
B) Your directory names are numeric, not alphanumeric and not randomly long
C) Your computer specs are missing
Now can you please explain why you think that this is faster?
I believe that if I write a minimal tool in C it would be much faster than rsync.
I would have to read the fs index if existing, otherwise create a list of directories/files then unlink it in parallel in the inode order. Later optimize ops based on the fs.
I don't think tmpfs is involved at all; it's just moving things out of the way instead of deleting, first. The actual delete runs in the background, so you can get an interactive shell back and keep working while the delete happens without blocking you. I usually do an approximate equivalent of just renaming the directory itself and making a new one in its place (and removing the renamed one in the background).
Comments
Even faster: mkdir ../.tmp${RANDOM} && mv ./* ../.tmp[0-9]* && rm -rf ../.tmp[0-9]* & #or the rsync trick
As long as ../ is on the same device, that should clear the directory instantaneously. It is the point, right? Of course, if you want an rm for lower IO-wait or lower CPU, use the rsync method, but if you want something that clear a directory as fast as possible, this is fast. Tested with for I in `seq 1 1000000`; do echo ${I} > ./${I};done;sync #^ much faster than "touch"
How is that mv ./* not going to blow through the argv limit with millions of files?
A) You're cheating by using the tmpfs filesystem! B) Your directory names are numeric, not alphanumeric and not randomly long C) Your computer specs are missing
Now can you please explain why you think that this is faster?
I believe that if I write a minimal tool in C it would be much faster than rsync.I would have to read the fs index if existing, otherwise create a list of directories/files then unlink it in parallel in the inode order. Later optimize ops based on the fs.
I don't think tmpfs is involved at all; it's just moving things out of the way instead of deleting, first. The actual delete runs in the background, so you can get an interactive shell back and keep working while the delete happens without blocking you. I usually do an approximate equivalent of just renaming the directory itself and making a new one in its place (and removing the renamed one in the background).
also no need for seq(1) binary, in Bash for i in {1..1000000}..