Pasta /home separada = boot lento

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.

Verifiquei exatamente a mesma coisa, aqui.

Quando a /home era só uma pasta dentro da partição-raiz das 4 distros, o tempo de boot ficava entre 10 e 15 segundos.

Agora que as /home e o Swap das distros fica num HDD, o tempo de boot foi para 30 ~ 50 segundos (varia bastante), conforme a distro.

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.

2 curtidas

So mover as pastas e criar um link simbólico apontando.

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.

Obrigado!

1 curtida

Olá :vulcan_salute:

É 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.

Usa plymouth?

Pode ser problema com ele.

Normalmente mascarando o wait dele resolve.

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.

1 curtida

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.

Resolvido
Consegui resolver o problema.

Eu fiz o seguinte.

  1. Dei boot no LiveCD de alguma distro
  2. Criei uma pasta na raiz da partição do sistema (do SSD) chamada dados
  3. Usei o comando chown marcos:marcos /dados pra obter permissão de leitura e escrita
  4. Copiei as pastas .cache, .config e .local da pasta /home (do HD) usando o comando
    rsync -av
  5. Renomeei as pastas que estavam no HD (pra poder reverter)
  6. Criei o link simbólico das pastas

Agora o boot do sistema nem leva 10 segundos!

1 curtida

Este tópico foi fechado automaticamente 3 dias depois da última resposta. Novas respostas não são mais permitidas.