4

On a system with linux there are 2 folders with aprox 12gb used(out of 500gb) and all inodes are used by some s

Bart De Vos
  • 17,911
  • 6
  • 63
  • 82
Bogdan Cosmin
  • 301
  • 1
  • 3
  • 10

1 Answers1

4

If you're on a relatively recent box just using something like

find /my/full/directory -type f -delete

You can be a little bit more subtle if you want to delete only some of the files by throwing in a pattern match.

Don't use find with xargs and rm, as this will spawn a new process for each group of files xargs passed to rm thus making it take even longer to complete.

goo
  • 2,868
  • 19
  • 15
  • The whole point of `xargs` is that it _does not_ spawn one process per file. – JdeBP Feb 10 '12 at 10:47
  • @JdeBP xargs may however complain about having too many arguments. – Andrew Feb 10 '12 at 10:49
  • 1
    Not had my caffeine fix this morning. Xargs will group the output of find and fork, exec rm for each group. With zillions of files this'll still be an overhead. On any case, this is likely to take a fair while if all the inodes have been used as one per file. – goo Feb 10 '12 at 11:03
  • No, it won't Andrew. Go and read its manual page. – JdeBP Feb 10 '12 at 12:22
  • 3
    The amount of overhead in fork+exec is going to be dwarfed by the amount of (synchronous) disc I/O involved in unlinking all of those directory entries (zeroing bitmaps and so forth). And the program image for `/bin/rm` will be cached. You've latched onto something that isn't actually a problem. The thing that you've entirely missed, on the other hand, is the safety risk of using `xargs` instead of `-execdir`. Interestingly, the manual is silent upon whether `-delete` has the same safety hole with pathnames that `-print0|xargs -0 /bin/rm --` does, or whether it uses `unlinkat()`. – JdeBP Feb 10 '12 at 12:30
  • I think it's less important if it spawns new processes or not. because you can not really use that system in the moment you use a read/write intensive process on the hard drive. after running the command the system was really sluggish because of the I/O, even if the memory and CPU used was pretty low – Bogdan Cosmin Feb 10 '12 at 15:39