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

[Aldrin Martoq]

On Wed, 2008-12-31 at 11:12 -0300, Horst H. von Brand wrote:
> Aldrin Martoq <amartoq en dcc.uchile.cl> wrote:
> > Actualmente, un disco usualmente tiene varios platos, supongamos 4.
> OK.
> > Luego, cuando leemos 1024KiB desde el sector 0, leera _al mismo tiempo_:
> Leera al mismo tiempo 1024KiB desde el sector 0, nada mas. Los discos estan
> en condiciones de transferir datos desde una unica cara (== cabezal) a la
> vez. Salvo dispositivos mas bien exoticos.

Hmmm no recuerdo desde cuando pensaba que los platos se leen/escriben
paralelamente, me impresiona que no sea asi siendo que es una mejora
bastante obvia.


> > Entonces tienes un ancho de banda de 1024KiB/dt == 4 veces mas rapido
> > que si leyeras desde un solo plato. Ahora, el costo de buscar esa
> > informacion (seek) no cambia.
> No. El ancho de banda no cambia.
> Lo que si cambia (internamente) es que los discos manejan extenso
> buffering, y si pides leer de la pista 30, sector 17, y el cabezal viene a
> caer en el sector 25 aprovecha de leer el resto de la pista a partir de
> alli y la guarda porque probablemente van a solicitar parte de eso
> pronto. Asi el ancho de banda que ves puede ser mayor que el con el que se
> leen datos fisicamente de la superficie del disco.

La idea es comparar solo la capa inferior, el almacenamiento en disco,
obviando todos los chiches extras. En este nivel se hacen pruebas de
leer/escribir secuencial/aleatorio, variando el taman~o de cada
requerimiento.


Para el resto, es posible que te topes con el cache del sistema
operativo antes que el del disco o la forma en como trabaja la
aplicacion... claramente es mucho mas complejo y por eso las pruebas
deben hacerse (lo mas cercano) con los datos reales, la aplicacion real
y el resto de sistemas involucrados, donde muchas cosas influyen en el
rendimiento global del sistema.

> > Ahora, si configuramos un RAID-5 con 5 discos por ejemplo, es la misma
> > historia: Cuando leemos 4096KiB desde el sector 0, leera _al mismo
> > tiempo_:
> > - 1024KiB del sector 0 del 1er disco,
> > - 1024KiB del sector 0 del 2do disco,
> > - 1024KiB del sector 0 del 3er disco,
> > - 1024KiB del sector 0 del 4to disco,
> > - 1024KiB del sector 0 del 5to disco (paridad)
> Con esto obtienes 1024KiB de datos utiles, lo otro es unicamente para poder
> verificar paridad (y corregir datos dan~ados que se hayan leido). O sea, el
> tiempo de esto (idealmente) es igual a leer de un disco + el tiempo para
> verificar paridad (o corregir, segun sea el caso). Pero ver mas abajo
> porque esto no es tan simple.

No, obtienes 4MiB de datos utiles (1Mib de los discos 1-4); el "sector
0" es el sector del disco virtual. Aqui la idea es que el block_size del
sistema operativo es de 4MiB y el strip en cada disco es de 1MiB.

> > Tienes un ancho de banda de 4096Kib/dt == 4 veces mas rapido (porque el
> > ultimo disco es para validacion de paridad).
> No...
> > Esto funciona porque los discos estas rotando al mismo tiempo y la
> > controladora sabe manejar eso. Luego, el costo de busqueda (seek) es el
> > mismo que en un solo disco. En discos/controladoras mas baratos, el seek
> > time sera peor.
> Idealmente, el seek es el mismo. Pero seria bien dificil asegurar
> sincronizar tanto los discos (considera el remapeo "transparente" de
> sectores malos), y definitivamente no hay como sincronizar los discos en
> giro, asi que la latencia rotacional (que sera la mayor de todas!) empeora.
> > pero tienes el mismo
> > tiempo de busqueda.
> Empeora, por lo anterior.

Pero de todas formas mejora. El caso base es el peor tiempo de un solo
disco, el mejor caso es el mejor tiempo de un solo disco cuando estan
todos los discos sincronizados, la realidad esta por ahi entremedio,
basta hacer pruebas de un disco huacho versus el arreglo.

Entonces el ancho de banda aumenta. Y el tiempo de busqueda esta entre
el peor y el mejor de un disco solo; yep, debe disminuir pero ahi esta
el trade entre una cosa y la otra.



> > > > Podrias intentarlo con systemtap o por ultimo strace y nos
> > > cuentas ;)
> > > 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...

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.


-- 
Aldrin Martoq <amartoq en dcc.uchile.cl>
http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : no disponible
Tipo       : application/pgp-signature
Tamaño     : 197 bytes
Descripción: This is a digitally signed message part
Url        : http://listas.inf.utfsm.cl/pipermail/linux/attachments/20081231/0336029e/attachment.bin