[eside-ghost] Lentitud al listar ficheros

Jue Mayo 31 15:25:31 CEST 2012

Me parece super interesante el tema. Aquí:

http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-05/msg07079.html

Comentan los siguiente:

"The problem is that unless the user is deleting a *huge* number of
files, it's rare that the directory entry block goes completely empty.
If you shrink from 15,000 messages to 12,000 messages, say, because of
the fact that we use a hashed b-tree as our data structure, the leaf
blocks in the btree generally still contain some directory entries.
So to fix this we need to actually coalesce directory leaf blocks on
the fly, on top of everything else that I had mentioned. It's
certianly doable, but again, someone would have to submit a patch. We
might get around to it one of these days, but plates of those of us
who are doing ext4 are pretty full with higher priority items at
present.
"

Por lo que parece que no encojen la estrucutra B-tree que se monta para
acceder a los inodos, por lo que, aunque tengas dos ficheros si estaba ahí
metido todo el demonio, la estructura del Btree, se la tiene que recorrer
entera.

 Ya dicen, que ala, que algún valiente mande algún parche (jajaja) que
ellos están con ext4 (esto es del 2009) :P.

2012/5/31 Bruno Gonzalez <stenyak en gmail.com>

> Bueno, he avanzado algo. Si alguien controla un poco de sistemas de
> ficheros, fijo que sabe decirme cuál es el problema.
>
> Primera prueba:
>  - Reinicio
>  - Me explota la fuente de alimentación según pasaba el POST (Murphy
> haciendo horas extra...). Cambio la fuente.
>  - Le paso un fsck (todo impoluto, no se queja de nada), y de seguido un
> fsck -D para arreglar sus historias esas. No tarda ni 1 segundo en terminar
> (no sé yo si hace algo realmente xD).
>  - Reinicio again, hago un ls, y...
> $ time ls directorio
> real 0m23.316s
> user 0m0.000s
> sys 0m0.180s
>
> Nada, sigue yendo igual de lento la primera vez, 23 segundos.
>
>
> Segunda prueba:
> Duplico el directorio que da problemas y reinicio:
> $ cp -a directorio_viejo directorio_nuevo
> $ sudo reboot
> Compruebo que el directorio viejo sigue tardando 23 segundos, pero el
> nuevo no tarda ni 1 décima de segundo!
>
> Más interesante aún:
> $ diff -r directorio_viejo directorio_nuevo
> Ambos son clavados, dice.
>
> $ du -sh directorio_*
> 848K directorio_nuevo
> 12M directorio_viejo
> La copia idéntica ocupa 15 veces menos *en disco*.
>
> Vamos a desconfiar del diff recursivo, comprobemos los contenidos byte a
> byte:
> $ find directorio_viejo  -exec cat {} \; | wc -c
> 696432
> $ find directorio_nuevo  -exec cat {} \; | wc -c
> 696432
> Y si le paso vimdiff, todos esos 696432 bytes son idénticos. Así q
> definitivamente es la misma información.
>
>
> Conclusión: toca desechar el mito de que en linux no hay que pasar defrag,
> o qué? =D
> Alguna otra idea?
>
> Con usar la copia nueva se me soluciona el problema, pero quiero saber la
> solución real, por pura curiosidad científica.
>
>
> 2012/5/31 Jon Ander Ortiz <jonbaine en gmail.com>
>
>> Aupa!!!
>>
>> Como curiosidad te puedes implementar un "ls" o algo parecido bypasseando
>> las cachés de disco.
>> Con hacer un open con el flag O_DIRECT, bypasseas todas las cachés y
>> demás morrallas así que puedes tener un resultado de referencia para
>> comparar ya que te quitas las cachés de enmedio, y ver el rendimiento de tu
>> sistema de ficheros / disco sin las cachés.
>>
>> De esta manera, puedes ver si es que tu sistema de ficheros va así (yo
>> que se.. movidas chungas de ext), e incluso compararlo con otro disco de
>> características parecidas a ver si está crujido.
>>
>> Un saludo!!
>> Jonan
>>
>>
>> 2012/5/31 Bruno Gonzalez <stenyak en gmail.com>
>>
>>> Si, la caché juega su papel, pero el problema no es que linux consiga
>>> acelerar el proceso, sino que el proceso pueda ir tan lento en primer lugar.
>>>
>>> Según leo en serverfault, si el directorio ha tenido en el pasado muchos
>>> ficheros (en mi caso he tenido varios miles), incluso si ahora no tiene más
>>> que 2 archivos, puede ser necesario optimizar los índices de la trócola
>>> derecha de ext2/3/4 con:
>>> # e2fsck -D /dev/<particion>
>>>
>>> No lo he probado aún, más tarde reiniciaré con una live y os comento los
>>> resultados.
>>> Mientras tanto, si a alguien se le ocurre alguna posible solución que no
>>> implique reiniciar, bienvenida será :-)
>>>
>>>
>>> 2012/5/31 ALi <osatien en gmail.com>
>>>
>>>> yo creo que se trata de alguna cache
>>>> porque me pasa a mi parecido con find .... la primera vez que busca la
>>>> leche, pero las siguientes van muy rapido, supongo que sera parecido. eso
>>>> si, desconozco de donde almacena la cache
>>>>
>>>>
>>>> 2012/5/31 Pablo Garaizar Sagarminaga <garaizar en deusto.es>
>>>>
>>>>> Aupa!
>>>>>
>>>>> el Thu, 31 May 2012 10:56:40 +0200 Bruno Gonzalez <stenyak en gmail.com>
>>>>> decía:
>>>>>
>>>>> > $ dmesg no dice nada raro... Alguien tiene idea de qué podría ser?
>>>>> > Sectores muertos del disco duro tal vez?
>>>>> > Es el único directorio en el que me ha pasado.
>>>>>
>>>>> Ni idea, pero yo le tiraría un ltrace al ls cuando sepas que va a
>>>>> pasar, para ver si ves dónde puede estar quedándose atascado. Si no ves
>>>>> nada, strace.
>>>>>
>>>>> --
>>>>>  Pablo Garaizar Sagarminaga
>>>>>  Universidad de Deusto
>>>>>  Avda. de las Universidades 24
>>>>>  48007 Bilbao - Spain
>>>>>
>>>>>  Phone:       +34-94-4139000 Ext 2512
>>>>>  Fax:                  +34-94-4139101
>>>>>
>>>>> _______________________________________________
>>>>> eside-ghost mailing list
>>>>> eside-ghost en listas.deusto.es
>>>>> https://listas.deusto.es/mailman/listinfo/eside-ghost
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> eside-ghost mailing list
>>>> eside-ghost en listas.deusto.es
>>>> https://listas.deusto.es/mailman/listinfo/eside-ghost
>>>>
>>>
>>>
>>>
>>> --
>>> Saludos,
>>>      Bruno González
>>>
>>> _______________________________________________
>>> Jabber: stenyak AT gmail.com
>>> http://www.stenyak.com
>>>
>>> _______________________________________________
>>> eside-ghost mailing list
>>> eside-ghost en listas.deusto.es
>>> https://listas.deusto.es/mailman/listinfo/eside-ghost
>>>
>>
>>
>> _______________________________________________
>> eside-ghost mailing list
>> eside-ghost en listas.deusto.es
>> https://listas.deusto.es/mailman/listinfo/eside-ghost
>>
>
>
>
> --
> Saludos,
>      Bruno González
>
> _______________________________________________
> Jabber: stenyak AT gmail.com
> http://www.stenyak.com
>
> _______________________________________________
> eside-ghost mailing list
> eside-ghost en listas.deusto.es
> https://listas.deusto.es/mailman/listinfo/eside-ghost
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://listas.deusto.es/mailman/private/eside-ghost/attachments/20120531/437ea96c/attachment.html>