strip/block size y otros temas de RAID (largo)

[Alvaro Herrera]

Aldrin Martoq escribió:
> On Wed, 2008-12-31 at 11:12 -0300, Horst H. von Brand wrote:

> > > > No creo que strace(1) ayude mucho aca?
> > > Con strace puedes sacar el tamano de un write por ejemplo,
> > Cierto.
> > > y el tiempo que tomo.
> > El tiempo que tomo en retornar de la llamada al sistema, nada mas.
> > >           Es un DTrace/Systemtap de los pobres ;)
> > Si y no. Es una herramienta para otros usos.
> 
> Han hecho un "strace -c /bin/ls /" por ejemplo? Es basicamente el mismo
> tipo de informacion que uno necesita cuando usa DTrace o Systemtap. Me
> imagino que se podria modificar para extraer mas datos relevantes que a
> uno le pueda interesar...

El problema de strace es que muestra la información a un nivel muy
lejano.  Sólo tienes el dato de cuando se entra y sale de cada syscall,
pero no sabes nada de qué cosas pasan por debajo (por ej. cuales
llamadas a "read" leen del disco y cuales traen cosas de algún cache).
Ni tampoco qué cosas pasan más arriba, por ejemplo dónde se hace cada
llamada a read, o por qué la aplicación parece estar haciendo un montón
de llamadas a stat() que en realidad las hace libc o alguna otra
biblioteca.

Para diagnosticar algunos problemas yo he usado oprofile, que es
bastante más que strace (pero bastante menos que DTrace).

> Uno de los problemas que me han ocurrido con strace es que las
> aplicaciones se ven afectadas (creo que el tema de signals)... Varias
> veces hacer strace a un proceso java he terminado con la jvm colgada.

Claro, eso puede ser un problema que no tienes con DTrace.  Lo otro es
que strace afecta el rendimiento de la aplicación, mientras que DTrace
es mucho menos intrusivo en este aspecto.

-- 
Alvaro Herrera                http://www.amazon.com/gp/registry/3BP7BYG9PUGI8
"Most hackers will be perfectly comfortable conceptualizing users as entropy
 sources, so let's move on."                               (Nathaniel Smith)