Olá, eu tenho um SSD de 120Gb e um HD de 1Tr.
Devido ao pouco espaço em SSDs eu decidi adotar uma configuração que mantém a pasta /home no HD e o sistema em sí apenas no SSD.
Porém o tempo de boot aumentou significativamente, demorando de 10 segundos para quase 30 segundos.
Eu queria saber se esse problema de separar a pasta home com o tempo de boot é normal, quando eu usava Windows a pasta de Desktop, Documentos, Downlods ficavam no HD e as outras coisas no SSD e o tempo de boot no Windows quase não tinha impacto.
Se não for normal… alguem sabe dizer o que tá causando isso?
Uso KDE Neon com Ubuntu 20.04.
Que pena, não existe algum meio para separar os arquivos .config e .local, que ficam na /home para o SSD? não queria sofrer impacto por separar a pasta /home da partição do sistema…
Ao menos a ideia era deixar os arquivos usados pelo sistema no SSD mesmo e as outras coisas no HD.
Imagino – nunca experimentei – que você pode usar as subpastas Downloads, Imagens (etc.) da /home (no SSD) como links para pastas que você criar no HDD.
Desse modo, quando você usar essas subpastas da /home estará, na verdade, abrindo / salvando / editando no HDD – enquanto seus arquivos ocultos (configurações) continuarão no SSD.
Mas como disse antes, nunca fiz essa experiência. – Vários colegas aqui recomendam isso, e devem ter uma resposta mais concreta.
Boa ideia, era o que eu fazia no Windows mesmo.
Achei que separar a pasta /home era o suficiente, não considerei mexer com links simbólicos, pra isolar apenas algumas coisas e as outras ficarem no SSD mesmo.
É normal que fique mais lento por você ter dividido o sistema em outro dispositivo, pois, diferente do Windows, as pastas configuração, cache, lixeira, etc., do Linux que ficam na home (pastas que ficam escondidas) são sempre acessadas pelo sistema e apps que estão na /.
Vou dar um exemplo meu! Antigamente tinha o meu SSD dividido nas partições / e /home e gosto de instalar todos os meus Flatpaks na home (basta instalar um app ou adicionar o repositório com o parâmentro --user). Nisso os apps demoravam um pouco mais para iniciar, justamente por estar em um partição diferente.
Enfim, todas essas trocas que acontecem, mesmo até no mesmo disco, fazem com que haja um atraso na leitura e escrita.
Certo, queria um meio de justamente manter apenas as pastas de configuração e cache no SSD e manter absolutamente o restante no HD.
Estou avaliando usar os links simbólicos, mas o sistema unionfs andou me chamando a atenção.
O problema agora é encontrar um plano eficiente de manter apenas as pastas .local.config e .cache no SSD e o restante no HD mesmo, em teoria é isso, agora estou procurando a forma certa de colocar isso em prática.
É… eu vi vocês comentando sobre link simbólico, aí pensei um lance meio doido que seria mais ou menos assim:
1º Crie uma pasta no / com o seu nome de usuário (pensei no / mas pode ser qualquer lugar por ali, e também qualquer nome), para isso você irá precisa ser root;
2º Defina o dono dessa pasta como seu usuário e também defina o grupo no qual deve ter o mesmo nome do seu usuário, e nisso dê as mesmas permissões que as pastas que irá copiar tem;
Seria algo assim:
3º Cheque se está tudo certo tentando criar arquivos e excluir coisas nela já com o seu usuário (ou seja, não mais como root), e, se sim, copie as pastas que deseja;
4º Feito isso, você terá que criar os links simbólicos de cada pasta que copiou no exato mesmo local, mas também antes terá que apagá-las para criar tais links, e bem… como o sistema se comportará com pastas tão importantes e provavelmente grandes sumirem do nada? Será que permitirá apága-las? Será que não pois há algum processo usando algum arquivo dentro delas? Rapaz… não sei dizer.
É um tanto arriscado, mas até acho que deve dar certo.
Tentando diretamente no sistema em funcionamento creio que não daria certo, mas existe a opção de dar boot em uma LiveCD e de lá fazer a criação dos links simbólicos… copiar e deletar pastas e arquivos… e por fim usar o chroot para acessar o shell do sistema.
Vou fazer um teste com as pastas .config e .cache e ver como o sistema se comporta.