Ontem recebi minha nova estação de trabalho com:
- 120 GB - OCZ Vertex3 IOPS MÁX.
- 300 GB - Western Digital Velociraptor (10k RPM, média de busca de cerca de 4ms)
- 2x2TB Samsung Ecogreen F4
O sistema rodará Ubuntu com o objetivo principal de desenvolver muito Java. Ocasionalmente tenho que desenvolver Java em uma VM Windows; para isso preciso de VMs rápidas. Eu li muito sobre o desgaste do SSD e talvez seja uma má ideia colocar o espaço de trabalho do Eclipse no SSD, por causa de todas as pequenas gravações que as compilações fazem. Talvez o espaço de trabalho (e portanto /home) possa encontrar um lugar melhor no Velociraptor, que é bem rápido.
Como devo particionar tudo para tirar o máximo proveito disso? Eu estou aberto a quaisquer sugestões. LVM também pode ser uma opção. Talvez colocar uma terceira partição no SSD para uma imagem do VirtualBox seja uma boa ideia.
Atualmente estou pensando:
- SSD: 2GB /boot, espaço restante para /
- Velociraptor: LVM abrangendo toda a unidade.
- 150 GB /casa
- Espaço restante para /virtualMachines ou algo parecido
- Unidades Samsung (LVM em ambos ou um grupo de volumes para cada? - Este último seria melhor em termos de segurança de dados, porque se uma unidade em um grupo de grandes volumes falhar, tudo será perdido)
- Partições para dados, arquivo, etc.
Responder1
Existe outra opção se a confiabilidade, o nivelamento de desgaste e a diferença entre a velocidade de gravação e a velocidade de leitura forem preocupantes:
eu tenho umCartão 9010unidade RAM com bateria a partir da qual executo o Linux. Custará mais para preencher do que o custo de um SSD médio, mas você terá algumas vantagens:
- Velocidades de leitura rápidas E velocidades de gravação rápidas. Os SSDs têm velocidades de leitura muito rápidas e velocidades de gravação um pouco menos rápidas.
- Não é necessário nivelamento de desgaste.
- Não há preocupação com a gravação de discos cheios mais lentamente do que os vazios, como existe em SSDs
- Os picos de energia são cobertos pela bateria interna por cerca de um dia, e você também pode usar a parede externa para alimentar o ram-drive (além da bateria de reserva interna).
- O armazenamento de dados por mais tempo do que a vida útil da bateria é resolvido pelo cartão SD embutido na unidade: quando a energia é desligada e a voltagem da bateria atinge um certo nível baixo, o RAM-Drive faz backup do conteúdo da memória em um compact flash de 64 GB cartão que está embutido na frente da unidade RAM e, ao ligar, ele copia os dados do cartão SD de volta para o Ram na unidade RAM.
Para responder diretamente a parte da pergunta, como organizar partições em um SSD (ou unidade RAM):
Coloquei tudo, exceto /homeno drive ram. /homevai para um disco rígido. São necessários cerca de 5 GB para o Slackware64, então, em um drive de 32 GB de RAM, tenho muito espaço extra para desenvolvimento.
Você não precisa fazer seu trabalho em /home, embora esse seja o "jeito Linux" normal; em vez disso, pense em criar um diretório na árvore do Linux como /javaou /projectsque estaria em sua unidade RAM, definindo permissões e propriedade para que seu usuário possa para usar esse diretório e colocar seus projetos na unidade SSD/RAM para obter velocidade. Coloque seu sistema operacional/ferramentas/código-fonte na unidade RAM, trabalhe lá e, em seguida, tenha um script de desligamento que copie seu trabalho diário para o disco rígido.
Como medida de cinto e suspensórios, escrevi alguns scripts simples que fazem backup de arquivos importantes criados pelo usuário que estão na unidade RAM (ou SSD) em caso de problemas. Arquivos como o seu /etc/fstabe /etc/X11/xorg.confque podem ser difíceis de acertarrapidamente(especialmente se você tiver vários reprodutores de mp3 no fstab ou uma configuração complicada de monitor no xorg.conf, etc., nesses arquivos), se você tiver problemas com o SSD/RAM sendo embaralhado a qualquer momento.
Eu também tenho um par de scripts que fazem backup/restauração de cada arquivo da unidade RAM para um diretório no disco rígido, apenas para garantir. Menciono esses scripts porque outra resposta mencionou problemas de confiabilidade com SSDs (ou unidades de RAM). Os scripts me fornecem uma medida extra de backup e recuperação fácil, caso algo dê errado em algum momento. Configure um cron job para fazer backup várias vezes ao dia, se desejar, o que não é uma má ideia.
Então, o que eu faço:
/no SSD/work(/javaou/projectsoutro) para sua área de trabalho, no SSD/homeem um disco rígido/usr/scripts(criado para scripts feitos pelo usuário)- scripts para fazer backup de arquivos de configuração do usuário do SSD para o disco rígido
- scripts para copiar completamente a unidade RAM para um disco rígido.
A unidade RAM tem um tempo de acesso de 0,01 ms de acordo com o site. É muito mais rápido que um HD mas não o dobro (como alguém disse anteriormente).
Responder2
SSD não é confiável como HDD, é melhor usá-lo como arquivos temporários/página/scratch, em vez de inicialização. Como você possui o Velociraptor, o SSD não é necessário.
No escritório, uso SSD como disco principal e desenvolvo aplicativos C# no Windows XP. O Visual Studio cria e executa rapidamente para depurar meus projetos. Eu também uso SSD no ambiente Hyper-V como arquivos de página/swap/temp para respirar o HDD. Se você precisar de maior desempenho, useeBoostrpara armazenar em cache os arquivos mais usados, também diminui o uso do HDD, especialmente em um servidor web.