<html><head></head><body>Having been bit by rm before, I now do a mv oldname newname on the dir to be removed and let it sit for a day or more to see who screams. Same process works in a dir to create a new dir called delete-me and mv the files into delete-me. Do a cleanout later after user screams subside.<br><br>I only care about my efficiency. The computer exists to do my bidding. It's nice to not eat up resources on SA stuff, but if it takes "too long" to implement, my time is more valuable.<br><br><div class="gmail_quote">On June 29, 2022 12:27:43 PM EDT, Bob Toxen via Ale <ale@ale.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Efficiency is very close since neither involves a fork/exec sequence (which is very expensive).<br>Do whichever you are most comfortable with.<br><br>Since I am very paranoid about "rm -rf" in case of mistyping, I might use the find<br>with a -name thusly:<br><br> find dir1 -type f -name '*.stupid_log_file_ext' -delete<br><br>I might add before the -delete and put in root's crontab:<br><br> ! -mtime +365<br><br>The "find" certainly needs to do a "stat()" system call which has a slight overhead.<br>However, the "rm -rf" almost certainly has do a "stat()" as well to determine if<br>each file is a directory (that requires a "rmdir()" system call instead of an<br>"unlink()" system call.<br><br>The "rm -rf" might be smart enough to just do an "unlink()" call and if it<br>returns the error EISDIR (error it is a directory) it then would recursively<br>delete the files and dirs in that dir and then do an "unlink()" call.<br><br>In either case each file's (and dir's) inode would need to be read off of<br>disk to know the disk blocks to put on the free list.<br><br>Bob<br><br>On Wed, Jun 29, 2022 at 11:18:24AM -0400, Geoffrey Myers via Ale wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Looking for some advice for the best way to delete a large number of<br>files spread across a large number of directories on an NFS share. RHEL7<br></blockquote><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">There are 6 directories of the form:<br></blockquote><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">dir1/month/day/hour/minute/<br>.<br>.<br>dir6/month/day/hour/minute/<br></blockquote><br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">There are only files in the minute???s directories.<br></blockquote><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">which is a more efficient solution?<br></blockquote><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">1. find dir1 -type f -delete<br>2. rm -rf dir1<br></blockquote><br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Regarding #2, the directories will be recreated by the application.<br></blockquote><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">--<br>Until later, Geof<hr>Ale mailing list<br>Ale@ale.org<br><a href="https://mail.ale.org/mailman/listinfo/ale">https://mail.ale.org/mailman/listinfo/ale</a><br>See JOBS, ANNOUNCE and SCHOOLS lists at<br><a href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a><br></blockquote><hr>Ale mailing list<br>Ale@ale.org<br><a href="https://mail.ale.org/mailman/listinfo/ale">https://mail.ale.org/mailman/listinfo/ale</a><br>See JOBS, ANNOUNCE and SCHOOLS lists at<br><a href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a><br></pre></blockquote></div><br>-- <br>Computers amplify human error<br>Super computers are really cool</body></html>