On 04/14/2015 05:15 AM, Reco wrote:
  Hi.

On Tue, Apr 14, 2015 at 09:22:15AM +0200, Petter Adsen wrote:
/snip/
2015-04-13 14:39 GMT+02:00 Vincent Lefevre <vinc...@vinc17.net>:
The problem is that this operation is (always?) very slow:
something like 100 seconds (1 minute and 40 seconds). It has
been reproducible for several months. The logs show nothing
during this operation.

Any idea?
     Maybe the directory is very large (even though its empty).
Try

ls -ld tmp.

  and see if the file "tmp" is large.
Thanks! I didn't know that (I thought that the file system would
automatically "optimize" directories when files are removed, so
I've never looked closely at their size). Indeed:

ypig:~/eftests> ls -ld tmp
drwxr-xr-x 2 vlefevre vlefevre 29655040 2015-04-13 15:25:55 tmp/
Can someone please enlighten me as to why the entry for this
directory is so large, even though it is empty? Since it's
apparently obvious to everyone else, I would very much like to
know :)
A case study:

$ mkdir tmp
$ du -sxh tmp
4.0K    tmp
$ for x in {1..100000}; do touch tmp/$x; done
$ du -sxh tmp
2.1M    tmp
$ find tmp -type f | xargs rm
$ du -sxh tmp
2.1M    tmp
$ ls tmp | wc -l
0

Removing files from the directory does not change directory's inode
size. If using ext4, at least.

/snip/

What is the best way of solving this? Since the directory is empty, can you
just do an rmdir dirname ? Now if there are one or two files in it, will it
shrink the directory to fit them, as I think you are saying? If not, then
how?

--doug


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/552d53e8.2030...@optonline.net

Reply via email to