1

I usually remove an entire directory at once with rm -rf. I noticed just now that this takes longer the larger the directory is (reckoned recursively).

Do unix-like systems expose an alternative way to delete a directory that operates in constant time? It seems it should be possible to remove a directory 'directly', without touching the contents at all, which are now inaccessible.

Is there some characteristic of file systems that forces you to recursively walk the contents of a directory in order to delete the directory itself?

2

When you delete directory, you have to delete its content recursively. Why is it so?

Simplifying we can say that «directory» is file, which contains list of pairs . What will happens, if you just "free blocks of directory on a drive"?

Let's consider deleting of regular files. Program (like rm) calls unlink() system call. Operation System (and more specifically, file system driver) checks count of hard links (filename in directory in previous paragraph). If it is zero and file is not opened, it can be physically deleted. Thus, we know how to delete file.

Now let's look to directory deletion again. When you just free blocks, you don't unlink files in it, you don't decrement counter of hard links for any file in directory. And for any file in subdirectories, subsubdirectories, etc. What is conclusion? Exactly, we need to do unlink for all files in the directory that we remove, because we don't want to get unremovable garbage in File System.

Thus, you can use @SYN's solution (running rm in background), but there is no way to remove directory in constant time.

  • Well done for actually answering the question. "Is it possible to delete a directory in constant time?" No, it is not. +1 – Wildcard Feb 10 '17 at 0:05
  • This answer isn't terribly good. There is no technical reason why you can't remove a directory tree in O(1). The "unremovable garbage" that might result from not decrementing hard link counts could be dealt with by having a background cleaner / fsck. – DepressedDaniel Feb 10 '17 at 0:14
  • @DepressedDaniel, you're probably right. But with two caveats. First, user feel the "constant time", but in real it isn't so. And second, your idea may be good, but i don't know any real implementation of it. – ValeriyKr Feb 10 '17 at 6:45
1

If the directory is mounted on its own filesystem, you may unmount it, recreate the it with newfs, and remount it. That will take the same amount of time regardless of the size of the directory.

1

Do unix-like systems expose an alternative way to delete a directory that operates in constant time? It seems it should be possible to remove a directory 'directly', without touching the contents at all, which are now inaccessible.

This is a question of filesystem implementation. Now most folks working in filesystems are not worried very much about rm -rf performance because it simply doesn't come up in the file server and database workloads that everyone is trying to optimize.

Note that btrfs supports ripping out a subtree in constant time - but you have to use a subvolume for it in advance.

  • Are there restrictions on hard links crossing submodule boundaries in btrfs? – Gregory Nisbet Feb 14 '17 at 16:49
  • @GregoryNisbet Dunno. Usually with btrfs what you'd do is make a copy-on-write copy anyways with cp --reflink=always (or =auto). This makes them kind of like separate files but sharing blocks when possible. I think there's even a cleaner for btrfs that re-shares blocks that have the same content from different files. btrfs.wiki.kernel.org/index.php/Deduplication – DepressedDaniel Feb 14 '17 at 22:17
0

Use:

rm -fr /path/to/directory &

This would background your command

You may list backgrounded tasks with jobs

A job ID would be listed. Which could be used attaching back to your process :

$ sleep 60 &
[1] 22316
$ jobs
[1]+  Running                 sleep 60 &
$ fg %1
sleep 60

Having already started your rm command, you may also hit Ctrl+Z, which would pause your command, then type bg to un-pause in background.

Note the list of jobs you may control with these commands are bound to your shell - and may only be recovered from current shell.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.