4 ms·
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 cle
by Elv13 13y ago
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"
- js2 13y agoHow is that mv ./* not going to blow through the argv limit with millions of files?
- joshbaptiste 13y agoalso no need for seq(1) binary, in Bash for i in {1..1000000}..
- X4 13y agoA) 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? mkdir ../.tmp${RANDOM} && mv ./* ../.tmp[0-9]* && rm -rf ../.tmp[0-9]* & 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.
- mook 13y agoI 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).