sangoo escribió:
Perdonad mi ignorancia, ¿qué o quién es el OP?
OP en los foros de internet hace referencia a "Original poster", es decir, la persona que abre un hilo planteando la temática y el sentido del mismo.
http://netforbeginners.about.com/od/internetlanguage/f/What-Is-OP.htm
http://www.ehow.com/info_12047160_op-mean-forums.html
irho escribió:
A ver, en mi primera opción estaba gestionarlo manualmente, pero me picó el gusanillo al leer un topic en applesfera, el cual citaré un extracto que me llamó mucho la atención
Es genial, como todo lo que escriben en esa web.
irho escribió:
por ejemplo en el manejo de las librerías que habitualmente usamos en el SSD y las que no aunque las tenemos instaladas estarán en el HDD. La contra la veo en el uso del SSD, que estará escribiendo constantemente, no?
Si por librerías entiendes algo tipo Kontakt, que son datos que se leen de disco y se vuelcan parcialmente a RAM, no interesa que esto ocurra la quinta vez que los cargas, que dependa de la frecuencia de uso, o de la fecha de última apertura. Te interesa que se transfieran rápido de disco a RAM cuando las abres, que no se produzcan
glitches, drifts o dropouts, independiéntemente de que las uses mucho o poco, y para eso han de estar en el SSD siempre.
En mi opinión, todo ese proceso de mover datos que hace FusionDrive puede estar bien para muchos usos y determinados perfiles de usuario, pero en ámbitos como el del software musical, en el que prima el factor realtime, no es lo ideal. Aqui la buena gestión de discos y particiones sigue siendo esencial, y en este caso FD no exime de esa responsabilidad al usuario y/o al administrador del sistema.
Poner la librería de Logic en el SSD igual no tiene tanta importancia (obviando fragmentación, etc), pero si usas Kontakt con un Rambuffer alto, el SSD es el sitio idóneo para ubicarlo. Si cargas una batería Abbey Road, o abres un proyecto en el que las muestras en RAM ocupen, pongamos 12GB, es cuando el SSD más se notará. En lugar de esperar minutos, serán segundos. Y en cualquier caso, aún con el Rambuffer al máximo, gran parte de las muestras se leerán desde disco. Me refiero a que aunque veamos que un instrumento ocupa X GB en disco, Kontakt solo cargará en RAM una parte del mismo (aún con el Rambuffer al máximo), el resto se leerá desde disco.
En el momento del volcado de disco a RAM, el SSD supone multiplicar la transferencia secuencial de lectura (que es el gran cuello de botella de los PCs sin SSD), y una vez cargados los datos, es la alta tasa de IOPS la que permite leer las partes que hay en disco de forma eficiente, sin apenas latencias, y sin incidencias derivadas del nivel de fragmentación.
En resumen, SSD es el sitio para SO, programas, librerías pesadas, y quizá archivos temporales grandes en los que se esté trabajando en ese momento (p.e, editando un vídeo). Cosas que requieren un acceso inmediato, simultáneo, y estable, con independencia de la frecuencia de uso, número de ejecuciones, u otros factores. Pero determinar cuáles son esas cosas no es algo que un software pueda hacer en base a estadísticas de uso. Es una
función humana, aunque ciértamente no para cualquiera.
Por eso, para el perfil mayoritario de usuario es una buena solución, y es probáblemente la razón por la que Apple ha visto la necesidad de hacer esto, dado el pequeño tamaño de los SSDs y de la más que previsible situación en la que se verían la mayoría de usuarios si hubiésen incluido el SSD y el HDD configurados como unidades independientes: El usuario llenaría el SSD en 4 dias, y empezaría a quejarse de que el equipo va lento.
-Sale un cartel cuando se llena, sí, pero para el usuario medio no resultaría fácil suponer qué puede mover o cómo tiene que hacerlo-. En cambio para un perfil más técnico de usuario, la configuración FD será más una molestia que una ventaja, y se optará por la gestión manual.
