Messages in this thread | | | Date | Thu, 11 Feb 1999 09:28:57 -0500 (EST) | From | Alexander Viro <> | Subject | Re: rm a_large_file takes too long under linux-2.2.1 (also unSTOPable) |
| |
On Thu, 11 Feb 1999, Matti Aarnio wrote:
> Sang Kang <kernel@mocha.sarang.net> wrote: > .... > > For the removing speed issue, I remember there was a patch that can be > > applied to 2.0.36 that speeds up a deletion process quite a bit (on > > Linuxmama I believe). I don't know if there was any discussion whether > > how safe it is, but I loved the patch. > > > > For the stopping issue, it has been my habit to suspend( = STOP) and do > > 'bg' whenever I want to do something else immediately after issuing 'rm'.
Erm??? What's wrong with rm <something> & ???
> > I don't see why the foreground process 'rm' must be blocked since whenever > > an 'rm' is issued, the kernel can simply launch a thread that removes > > the inodes - there is no point of blocking the process.
If you want it in background - out rm in background and be done with that. Why would you need a special thread for that?
> The criteria is not 'rm', like has been said here > earlier, the criteria is loosing the last reference > to the given file. > > Lets say, we have a large directory with lots of files > to clean up, if each reference loss would cause a new > thread to be created without bounds, we would soon have > thousands of threads doing the deletes.
Yup. If *that* is wanted - for i in *; do rm $i & ; done and watch the system brought on its knees.
> Even if such a thing would give fast response speeds, > there must be some limit at how many of them can be > running at the same time. > > As the cleanups of small files would happen faster than > cleanups of large files, thus presuming the count of large > files to be deleted to be fairly small, one can guess that > a limit around 10-20 deleter threads would be all what the > doctor ordered. If the limit is exceeded, deleter blocks > until the count comes down again (and then starts a new > thread, and increments the count..) > > Would you write it ? It should be a general VFS-layer thing.
It's userland thing.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |