[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: mutt: тормозит на sorting headers



* Yuriy Kaminskiy <yumkam@mail.ru> [2010-02-09 16:55:03+0300]
> On 09.02.2010 15:40, Roman Cheplyaka wrote:
> > Вот что сообщил strace -T (в угловых скобках - время проведенное в вызове)
> > 
> > open("/home/feuerbach/Mail/.spam/new", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 <0.000039>
> > fstat64(3, {st_mode=S_IFDIR|0700, st_size=5931008, ...}) = 0 <0.000019>
>                                             ^^^^^^^
> > getdents64(3, /* 30 entries */, 4096)   = 2512 <20.111790>
> > close(3)                                = 0 <0.000026>
> > 
> > Убирание .spam из muttrc действительно убрало тормоза.
> > 
> > Почему такое может быть? Директория /home/feuerbach/Mail/.spam/new содержит 28
> > файлов суммарным размером 7.3M. ФС ext3.
> ext3 не уменьшает размер каталогов после удаления большого числа файлов.
> В результате:
> 
> $ stat .|grep Size
>   Size: 1024      	Blocks: 2          IO Block: 1024   directory
> $ seq 1 1000|xargs touch
> $ stat .|grep Size
>   Size: 17408     	Blocks: 36         IO Block: 1024   directory
> $ seq 1 1000|xargs rm -f
> $ stat .|grep Size
>   Size: 17408     	Blocks: 36         IO Block: 1024   directory
> 
> Для сравнения, на reiserfs:
> 
> $ stat .|grep Size
>   Size: 48        	Blocks: 0          IO Block: 4096   directory
> $ seq 1 1000|xargs touch
> $ stat .|grep Size
>   Size: 24048     	Blocks: 47         IO Block: 4096   directory
> $ seq 1 1000|xargs rm -f
> $ stat .|grep Size
>   Size: 48        	Blocks: 0          IO Block: 4096   directory
> 
> Так как в этом каталоге /когда-то/ было очень большое число файлов (см.
> подчёркнутое в fstat), то подобный результат вполне ожидаем.
> 
> cp -al .spam/new{,.new}; rm -rf .spam/new; mv .spam/new{.new,}
> 
> (очевидно, это можно делать только когда никто к .spam/new обращатся не будет)

Здорово, спасибо. У меня выходит так:

  Size: 5931008         Blocks: 11608      IO Block: 4096   directory

Следующий вопрос: есть ли утилиты, которые могут почистить таких "зомби"?
mv и rm это хорошо, но если такую операцию хочется провести в масштабе всей
файловой системы? Ну и просто хочется чего-то менее hackish, чтоб можно было раз
в месяц запускать по крону и забыть о проблеме. Ведь проблема по определению
характерна для maildir'ов -- что-то падает в .new, потом переносится в .cur.

-- 
Roman I. Cheplyaka


Reply to: