Fedora 17 em um SSD

Aviso: apaguei tudo que existia nos discos.

Usando as mídias de teste do Fedora 17 (lançamento previsto para 22/05/2012): https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Primeiro passo foi limpar o SSD, zerando todas as células de memória flash com o comando SECURITY_ERASE do protocolo ATA. Num live CD:

# hdparm --security-set-pass p /dev/sda
# hdparm --security-erase p /dev/sda

Mais informações: ATA Secure Erase (SE) and hdparm (TinyApps.Org)

Depois, zerar o HD (300MiB):

# sgdisk -Z /dev/sdb
# dd if=/dev/zero of=/dev/sdb count=600k

Tudo limpinho agora. :-)

PARTICIONAMENTO

Hardware disponível: SSD OCZ Agility 3 60GB, HD Samsung HD103SJ 1TB.

Antes de tudo, nada de partição swap. Eu gosto de ter o mínimo possível de partições.

Esquema:


No Fedora 17, /tmp é um diretório normal dentro do diretório raiz. No meu esquema, quer dizer que ele fará parte da partição do SSD. /tmp é local para armazenamento de arquivos voláteis, sem garantia de durabilidade entre inicializações. Não é boa idéia tê-lo no SSD para gastar ciclos de gravação à toa. Na próxima leva de versões das distribuições (Fedora 18), está sendo acordado que o diretório /tmp passará a ser um tmpfs, ou seja, ficará na memória RAM, e que os programas que precisam gravar grande quantidade de dados na pasta temporária deverão usar /var/tmp. Este diretório é sustentado por um sistema de arquivos dentro de um disco de verdade e é menos volátil segundo o FHS.

Provavelmente 10GiB é exagero, mas que seja por excesso do que por escassez. O único aplicativo que imagino use parte disso é o Brasero ao fazer cópias de DVDs.

Features/tmp-on-tmpfs (Fedora Project Wiki)
/tmp or not /tmp? (Lennart's Blog)

TRIM

Adicionar a opção de montagem discard no /etc/fstab para a partição do SSD (meu diretório raiz). No momento que escrevo, suportam discard online: EXT4, XFS, Btrfs.

UUID=xxx    /        ext4    defaults,discard   1 1
UUID=yyy    /home    xfs     defaults           1 2
UUID=zzz    /tmp     ext4    defaults           1 2

Remontar a partição que abriga o diretório raiz para ativar o uso do comando TRIM na hora:

# mount -o remount /

Rodar o fstrim para liberar os setores que ficaram "órfãos" antes da opção discard ter sido ativada:

# fstrim -v /

Relacionado:
Suporte ao comando ATA TRIM no Linux
Complemento sobre o suporte a SSDs (e HDs com setores físicos de 4KiB) no Linux
TRIM e XFS...
O Parted Magic da OCZ
Entrando na era dos SSDs
XFS e SSDs (e HDs com setores físicos de 4KiB)

Comentários

  1. Fala, Marcos! Beleza?

    Então, cara... pô, vou manter o Debian Squeeze instalado no meu note usando SSD. Só que os dois primeiros comandos retornam erro do tipo input/output error. Enão, nem deu para continuar a "limpeza". É que não tenho mais como acessar o histórico do FF para resgatar o erro porque eu estava usando justamente o notebook com um LiveCD do Ubuntu.

    Enfim, já foi. Vou ver como o Debian se comporta no SSD. Abraços!

    ResponderExcluir
  2. Valério, salve!

    Dependendo do BIOS, ele pode configurar o SSD no estado "frozen". Neste caso, coloque o Linux (no live CD) em modo de espera e depois acorde-o. Esse ciclo de energização fará o SSD ficar "not frozen" e daí o secure erase funcionará.

    O atributo "frozem" você vê na saída do hdparm -I /dev/. Esta informação está no link "Mais informações".

    ResponderExcluir
  3. Opa!

    Então, agora estou com o sistema já instalado. Mas vou substituí-lo assim que sair o Wheezy. Aí farei o teste.

    Sobre o BIOS meu note é muito simples (nem calibrador de bateria tem) e bugado, acho. E ele não suspende ou hiberna direito no Linux. No Windows já é mais tranquilo. Pode falar o que quiser do Windows, mas ele funciona de alguma forma em qualquer equipamento com uma razoável compatibilidade.

    De qualquer forma obrigado pela força. Abraços!

    ResponderExcluir
  4. Opa! Voltando para dar um último feedback. Não dá para saber se o disco passa para o estado "no frozen" porque o aparelho até suspende, mas ao "acordá-lo" fica travado e com uma tela preta. Mas valeu pela força, Marcos! Abraços!

    ResponderExcluir
  5. Fala, Marcos!!

    Voltando para dar outro feedback sobre o estado frozen do meu SSD. Bom, instalei ele numa Gigabyte GA-M68MT-S2P e nem precisei entrar em modo de espera pelo Live CD. Já estava lá "not frozen" na saída do hdparm. Aliás, a placa suspende e retorna normalmente, ao contrário da MSI E350IA acima que trava ao suspender. Agora, pude zerar o SSD. Ah, antes usei o Gparted para zerar a tabela de partições do dispositivo.

    Qual é o motivo da placa travar um SSD quando não está em uso? Abraços do Valério!

    ResponderExcluir
  6. Corrigindo: o SSD ficava travado (frozen) no notebook e também na MSI E350IA, e ambos não voltavam do modo de espera pelo LiveCD.

    ResponderExcluir
  7. Depende do BIOS travar ou não. O motivo deve ser de segurança, para evitar apagamento acidental. Algo nessa linha. Cada fabricante faz do jeito que quiser pelo que vi. Na minha Biostar A880G+ também o BIOS não coloca o SSD em "frozen".

    Nem precisava ter excluído nada com o GParted. O comando SECURE_ERASE faz o firmware apagar tudo.

    O fato de não voltar do modo de espera é bug ou do kernel ou do BIOS (mais provável). BIOS bugados são como erva daninha...

    Abraço.

    ResponderExcluir

Postar um comentário