12

Would it make much difference in time to log in on the machine that has the directory before doing a rm -rf on the directory, or just rm -rf the directory over NFS?

Improve this question

2 Answers 2

Reset to default
13

Of course the ssh is the better.

Nfs uses a complex network protocol with various remote procedure calls and data synchronization waiting times. In the case of ssh, these don't apply.

Furthermore, there are many locks. File deletion in nfs works on this way:

  1. your rm command gives the unlink() syscall
  2. nfs driver converts it to a sunrpc request, sends it to the nfs server
  3. nfs server converts this sunrpc request back to an unlink() call
  4. executes this unlink() call on the remote side
  5. after it succeed, gives back the rpc reply message equivalent of "all right, it is done" to the client
  6. the kernel driver of the client-side converts this back to the exit code 0 of the unlink() call of your original rm
  7. rm iterates to the next file, goto 1

Now, the important thing is: between 2-7, rm has to wait. It could send the next unlink() call asynchronously, but it is a single-threaded, not event-oriented tool. Even if it could, it would still require tricky nfs mount flags. Until it doesn't get the result, it waits.

Nfs - and any network filesystem - is always much slower.

In many cases, you can make recursive deletions quasi-infinite speed with a trick:

  1. First move the directory to a different name (mv -vf oldfilms oldfilms-)
  2. Delete in the background (rm -rf oldfilms- &)

From many (but not all) aspects, this directory removal will look as if it had been happened in practically zero time.

Extension: As @el.pascado mentions in his excellent comment, actually 2-7 has to run 3x for any files:

  • to determine if it is a file or a directory (with an lstat() syscall),
  • then do accordingly. In the cases of ordinary files, unlink(), in the case of directories, opendir(), deleting all files/directories in it recursively, then closedir(), finally rmdir().
  • finally, iterate to the next directory entry with a readdir() call.

This, it requires 3 nfs RPC commands for files, and an additional 3 for directories.

Improve this answer
2
  • 2
    The nfs case is even worse. As question mentions -r flag, rm has to first check if file is a directory (lstat via nfs), open it (opendir via nfs), read its contents (readdir via nfs), and only then perform actual deletion as described in answer on every file found inside and recursing into subdirectories, close directory (closedir via nfs), and then repeat, for every found dir. Commented Aug 31, 2017 at 12:19
  • I think the parallel version of the gnu coreutils should have been long developed. Commented Apr 13, 2023 at 16:50
5

Yes. Well, maybe. It depends. For a small number of files and directories, it wouldn't do much difference.

Doing file operation in bulk on an NFS mounted directory is slow. If you have the opportunity to log into the NFS server itself and do them on the actual directory, then this would be quicker.

Let's test it by removing the OpenBSD ports collection that I have checked out from CVS and mounted over NFS:

On NFS server:

$ cd /export/shared/ports

$ du -hs .
2.6G    .

$ find . | wc -l
  179688

$ time rm -rf /export/shared/ports/*
0m20.87s real     0m00.12s user     0m04.62s system

On client (after restoring the original files from backup):

$ time rm -rf /usr/ports/*
6m49.73s real     0m01.55s user     1m08.96s system
Improve this answer
2
  • Is that the same without the wildcard? Does it go faster? Commented May 19, 2021 at 15:02
  • @Kiruahxh I used the wildcard there as the user I'm using does not have permissions to delete the /usr/ports directory itself. There would not be much difference in between deleting /usr/ports recursively compared to deleting all subdirectories and files that /usr/ports/* expands to. The difference would be of a magnitude that would get lost in the fluctuations of everything else that the system is doing. Commented May 19, 2021 at 15:11

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.