Existe outra opção se a confiabilidade, o nível de desgaste e a diferença entre a velocidade de gravação e a velocidade de leitura forem motivo de preocupação:
Eu tenho um Acard 9010 drive de RAM alimentado por bateria do qual eu rode o Linux. Vai custar mais para preencher do que o custo do SSD médio, mas você tem algumas vantagens:
- Velocidades de leitura rápidas E velocidades de gravação rápidas. Os SSDs têm velocidades de leitura realmente rápidas e velocidades de gravação um pouco menos rápidas.
- Nenhum nivelamento de desgaste é necessário.
- Não há preocupações sobre discos cheios gravando mais devagar que os vazios como existe no SSD
- Os blips de energia são cobertos pela bateria interna por aproximadamente um dia e você também pode usar a parede externa para alimentar a unidade de memória RAM (além da bateria de backup interna).
- Mais tempo do que o armazenamento da bateria em seus dados é solucionado pelo cartão SD embutido na unidade: quando a energia é desligada e a voltagem da bateria chega a um nível baixo, o RAM-Drive faz o backup do conteúdo da memória para 64 GB cartão flash compacto que está embutido na frente da unidade de RAM, em seguida, ao ligar, ele copia os dados do cartão SD de volta para o Ram na unidade de RAM.
Para responder diretamente a parte da pergunta, como organizar partições em uma unidade SSD (ou RAM):
Eu coloquei tudo, exceto /home na ram drive. /home entra em um disco rígido. Demora cerca de 5 GB para o Slackware64, então, a partir de uma unidade de 32 GB de RAM, tenho muito espaço extra para desenvolvimento.
Você não precisa fazer o seu trabalho em /home , embora seja a "maneira linux" normal; em vez disso, pense em criar um diretório na árvore do Linux como /java ou /projects , que estaria na sua ram unidade, definindo permissões e propriedade para que seu usuário possa usar esse diretório e colocar seus projetos na unidade SSD / RAM para velocidade. Coloque o seu código-fonte / OS / tools na unidade RAM, trabalhe lá e tenha um script de desligamento que copie seu trabalho diário para o disco rígido.
Como uma medida de cinto e suspensórios, escrevi alguns scripts simples que fazem backup dos arquivos importantes criados pelo usuário que estão na unidade RAM (ou SSD) em caso de problemas. Arquivos como o seu /etc/fstab e /etc/X11/xorg.conf que podem ser problemáticos para obter exatamente certo rapidamente (especialmente se você tiver um monte de mp3 players no fstab, ou uma configuração complicada do monitor no xorg.conf, etc ., nesses arquivos), se você teve problemas com SSD / RAM ficando embaralhado em qualquer ponto.
Eu também tenho um par de scripts que fazem backup / restauração de todos os arquivos na unidade RAM para um diretório de volta em um disco rígido, apenas no caso. Eu menciono esses scripts porque outra resposta mencionou os problemas de confiabilidade com SSDs (ou unidades de memória RAM). Os scripts me dão uma medida extra de backup e recuperação fácil, se as coisas derem errado em algum momento. Configure um trabalho de cronômetro para fazer backup várias vezes ao dia, se desejar, e não uma má ideia, de qualquer maneira.
Então, o que eu faço:
-
/no SSD -
/work(/javaou/projectsou outro) para sua área de trabalho, no SSD -
/homeem um disco rígido -
/usr/scripts(criado para scripts criados pelo usuário) - scripts para fazer backup dos arquivos de configuração do usuário do SSD para o disco rígido
- scripts para copiar completamente a unidade de RAM para um disco rígido.
A unidade de RAM tem um tempo de acesso de 0,01 ms, de acordo com o website. É muito mais rápido que um HD, mas não duplo (como alguém disse anteriormente).