[eside-ghost] Lentitud al listar ficheros

Jue Mayo 31 16:16:55 CEST 2012

Sip, el problema son los metadatos del inodo. El problema es que la
solución propuesta en serverfault, y que probé al mediodía (el fsck -D) no
era la correcta. Por la simple razón de que fsck pasa de tu culo si no le
pones el flag -f. Por eso no había tardado ni 1 segundo en ejecutarse:
efectivamente *no* había hecho nada. Mea culpa, supongo. O_o'

Total que acabo de pasarle un fsck -fD, y ahora *sí* que ha tardao media
hora. Y tras reiniciar, compruebo que ambos directorios tardan menos de una
décima en listar los ficheros. Oh yeah!

Conclusión: visto lo visto, voy a pasarle un fsck -fD a todos mis equipos
en cuanto pueda, y un par de veces al año. Tengo a chromium en casa que
tarda 5 segundos en cambiar de pestaña o crear una vacía, mientras firefox
va todo fresco; igual es el mismo problema y todo (algún directorio de
caché o temporales o yoquésé).

Gracias a todos por la ayuda!

2012/5/31 Jon Ander Ortiz <jonbaine en gmail.com>

> 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
>>
>
>
> _______________________________________________
> 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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://listas.deusto.es/mailman/private/eside-ghost/attachments/20120531/4916609c/attachment-0001.html>