Ayer recibí mi nueva estación de trabajo que incluye:
- 120 GB - IOPS MÁXIMOS de OCZ Vertex3
- 300 GB: Western Digital Velociraptor (10.000 RPM, aproximadamente 4 ms de búsqueda promedio)
- 2x2TB Samsung Ecoverde F4
El sistema ejecutará Ubuntu con el objetivo principal de realizar mucho desarrollo en Java. De vez en cuando tengo que desarrollar Java en una máquina virtual con Windows; Para esto necesito máquinas virtuales rápidas. Leí mucho sobre el desgaste de SSD y tal vez sea una mala idea colocar el espacio de trabajo de Eclipse en el SSD, debido a todas las pequeñas escrituras que realizan las compilaciones. Quizás el espacio de trabajo (y por lo tanto /home) pueda encontrar un lugar mejor en el Velociraptor, que es realmente rápido.
¿Cómo debo dividir todo para aprovecharlo al máximo? Estoy abierto a cualquier sugerencia. LVM también podría ser una opción. Quizás sería una buena idea poner una tercera partición en el SSD para una imagen de VirtualBox.
Actualmente estoy pensando:
- SSD: 2 GB/arranque, espacio restante para/
- Velociraptor: LVM que abarca todo el disco.
- 150 GB/hogar
- Espacio restante para /virtualMachines o algo así
- Unidades Samsung (¿LVM en ambas o un grupo de volúmenes para cada una? - Esto último sería mejor en términos de seguridad de los datos, porque si falla una unidad en un grupo de volúmenes grande, todo se pierde)
- Particiones para datos, archivos, etc.
Respuesta1
Existe otra opción si le preocupa la confiabilidad, la nivelación del desgaste y la diferencia entre la velocidad de escritura y la velocidad de lectura:
Yo tengo unTarjeta 9010Unidad RAM respaldada por batería desde la que ejecuto Linux. Cuesta más completarlo que el costo de un SSD promedio, pero obtienes algunas ventajas:
- Velocidades de lectura rápidas Y velocidades de escritura rápidas. Los SSD tienen velocidades de lectura realmente rápidas y velocidades de escritura algo menos rápidas.
- No se necesita nivelación de desgaste.
- No hay que preocuparse de que los discos llenos escriban más lentamente que los vacíos, como ocurre con los SSD.
- Los cortes de energía están cubiertos por la batería interna durante aproximadamente un día, y también puede usar la verruga de pared externa para alimentar la unidad ram (además de la batería interna de respaldo).
- El almacenamiento de datos que dura más que la batería se soluciona gracias a la tarjeta SD integrada en la unidad: una vez que se corta la alimentación y el voltaje de la batería llega a un cierto nivel bajo, la unidad RAM realiza una copia de seguridad del contenido de la memoria en una unidad flash compacta de 64 GB. tarjeta que está integrada en la parte frontal de la unidad RAM, luego, al encenderse, copia los datos de la tarjeta SD nuevamente a la RAM en la unidad RAM.
Para responder directamente parte de la pregunta, cómo organizar particiones en una unidad SSD (o unidad RAM):
Puse todo excepto /homeen la memoria RAM. /homeva en un disco duro. Se necesitan alrededor de 5 GB para Slackware64, por lo que en una unidad de RAM de 32 GB, tengo mucho espacio adicional para el desarrollo.
No tiene que hacer su trabajo en /home, aunque esa es la "forma Linux" normal; en su lugar, piense en crear un directorio en el árbol de Linux como /javao /projectsque estaría en su unidad RAM, configurando permisos y propiedad para que su usuario pueda para usar ese directorio y colocar sus proyectos en la unidad SSD/RAM para mayor velocidad. Coloque su sistema operativo/herramientas/código fuente en la unidad RAM, trabaje allí y luego tenga un script de apagado que copie su trabajo diario en el disco duro.
Como medida de seguridad, escribí un par de scripts simples que respaldan los archivos importantes creados por el usuario que se encuentran en la unidad RAM (o SSD) en caso de problemas. Archivos como el suyo /etc/fstaby /etc/X11/xorg.confque podrían resultar complicados de corregirrápidamente(especialmente si tiene un montón de reproductores de mp3 en fstab, o una configuración de monitor complicada en xorg.conf, etc., en esos archivos), si tuvo problemas con la codificación de SSD/RAM en algún momento.
También tengo un par de scripts que respaldan/restauran cada archivo en la unidad RAM en un directorio en el disco duro, por si acaso. Menciono esos scripts porque otra respuesta mencionó los problemas de confiabilidad con los SSD (o unidades RAM). Los scripts me brindan una medida adicional de respaldo y una fácil recuperación, en caso de que algo salga mal en algún momento. Configure un trabajo cronológico para realizar copias de seguridad varias veces al día si lo desea, de todos modos no es una mala idea.
Entonces, lo que hago:
/en el SSD/work(/javau/projectsu otro) para su área de trabajo, en el SSD/homeen un disco duro/usr/scripts(creado para scripts creados por el usuario)- scripts para hacer una copia de seguridad de los archivos de configuración del usuario desde SSD al disco duro
- scripts para copiar completamente la unidad RAM a un disco duro.
La unidad RAM tiene un tiempo de acceso de 0,01 ms según su sitio web. Es mucho más rápido que un HD pero no el doble (como alguien dijo antes).
Respuesta2
SSD no es confiable como HDD, es mejor usarlo como archivos temporales/de página/Scratch, en lugar de arrancar. Como tienes Velociraptor, SSD no es necesario.
En la oficina uso SSD para mi disco principal y desarrollo aplicaciones C# en Windows XP. Visual Studio compila y ejecuta rápidamente para depurar mis proyectos. También uso SSD en un entorno Hyper-V como archivos de página/intercambio/temperatura para darle un respiro al HDD. Si necesita un mayor rendimiento, utiliceeBoostrPara almacenar en caché los archivos más utilizados, también disminuye el uso del disco duro, especialmente en un servidor web.