Ir ao conteúdo
  • Cadastre-se

Marcos FRM

Membros Plenos
  • Total de itens

    571
  • Registro em

  • Última visita

  • Qualificações

    0%

Reputação

319

Informações gerais

  • Cidade e Estado
    Boston/MA
  • Sexo
    Masculino
  1. A partição EFI System (ESP) não deve estar sobre um arranjo RAID como você vez. Deve ser uma partição normal em sda ou sdb.
  2. No link que você passou diz que secure boot não é suportado no Debian 9. Se for desativado (mantendo o modo UEFI ativo), deve funcionar. Em "RAID for the EFI System Partition", diz que a partição EFI System tem que ficar num dos discos apenas -- diminui a resiliência, como comentei. Tire uma foto do particionamento que você está fazendo nessa instalação. Nota: você pode usar o VirtualBox para testar. Nas opções da máquina virtual, em "Sistema", marque "Habilitar EFI". Facilita tudo, até para fazer capturas de tela.
  3. O que não deu certo? Sem capturas de tela, mensagens de erro, é impossível ajudar.
  4. Em teoria dá para fazer com qualquer distribuição. Da última vez que usei um sistema assim (Espelhamento simples no Linux), foi com BIOS. Porém, com UEFI, é para ser tudo igual, exceto a necessidade de criar uma partição EFI System num dos discos (/boot/efi). Lembro de ter lido em algum lugar que daria para criar duas partições EFI System, uma em cada disco para obter resiliência no caso de um deles estragar. Nunca testei, contudo, para ver se o firmware não "se perde" com uma configuração desse tipo.
  5. Ubuntu e derivados têm /etc/cron.weekly/fstrim que faz isso para você (outras distros usam a solução oficial da suíte util-linux: fstrim.{service,timer}). Ah, e o firmware pode simplesmente ignorar o comando se assim desejar. Há modelos que zeram os setores trimados e outros que não, para ver como o firmware pode fazer o que bem entender. Desencana. Não coloque SSD num pedestal. Eu fiz isso lá em 2011 quando comprei meu primeiro SSD. Hoje, não dou a mínima para eles. Para mim são como discos rígidos. Apenas certifico que uma vez por semana o fstrim rodará, que é o padrão das distros de qualquer maneira, seja pelo arquivo .timer ou pelo cron... Apenas mereceria alguma configuração manual caso eu pegasse um modelo com NCQ TRIM. Daí valeria a pena tentar substituir TRIM periódico pela opção de montagem discard -- e pendurar uma ferradura na parede por garantia, pois os primeiros firmwares que implementavam o recurso eram bugados demais e corrompiam dados quando o sistema operacional enviava o comando.
  6. É assim mesmo. Essa discrepância entre as invocações do fstrim é porque o EXT4 memoriza quais blocos foram "trimados" até a próxima inicialização. Se você criar alguns arquivos, depois excluí-los e rodar o programa novamente, deverá mostrar quantidade de bytes maior que zero. Se não me engano, o XFS se comporta de forma diferente: sempre "trima" tudo. Note, contudo, que com a opção de montagem "discard" você não precisa rodar o fstrim regularmente, pois o sistema de arquivos já faz isso automaticamente. O problema, porém, é que, com a opção de montagem, em dispositivos que não suportem NCQ TRIM, há perda de desempenho. Escrevi algo sobre isso aqui. Talvez seja melhor remover "discard" do fstab e deixar o script /etc/cron.weekly/fstrim do Ubuntu tomar conta disso para você.
  7. Atualize por causa do novo microcódigo. É recomendado. Rode o InSpectre (https://www.grc.com/inspectre.htm) antes e depois de atualizar para comparar. Como você tem um Haswell, que possui INVPCID, deverá aparecer "Performance: GOOD", pois o kernel NT não terá que recorrer a flushes de TLB a cada troca de contexto com o espaço de usuário para mitigar a falha Meltdown. Nos Ivy Bridge e anteriores o impacto é maior. Mas confirma aí, pois faz algum tempo desde que pesquisei sobre o assunto.
  8. Muito esquisito. Deve ser algum bug do Clonezilla. Pois se o tamanho da partição ficou em 882,22 GB e o tamanho do sistema de arquivos em 440,66 GB, no gráfico do gerenciador de discos aparaceria o espaço não usado eu acho... Considerando que a partição tenha realmente ficado com os 882,22 GB, o Clonezilla pode ter feito lambança no redimensionamento do sistema de arquivos. Começaria tentando um simples chkdsk /f para ver no dá.
  9. Livros em português: Faz algum tempo que não dou uma olhada nas livrarias. Talvez tenha algo mais recente.
  10. Não. Discos removíveis geralmente não são montados via fstab. O udisks é encarregado pela tarefa (via GVfs em ambientes desktop que usam GTK). https://github.com/storaged-project/udisks https://gitlab.gnome.org/GNOME/gvfs Fica estático. É um arquivo de configuração, território do administrador.
  11. Há tempos é usado UUID no fstab para montar partições, de swap inclusas. Portanto, ao rodar o mkswap novamente (o que o GParted faz por baixo do capô), será gerado um UUID diferente e essa partição swap nova não será montada até o fstab ser atualizado (o UUID pode ser visto na saída de blkid).
  12. NTFS. Suporte a escrita no Linux é bom. FAT é suportado por todos os sistemas operacionais do planeta, mas a limitação de tamanho de arquivo (4 GiB) inviabiliza seu uso para qualquer coisa séria. Daria para usar EXT2/3/4 em conjunto com o Ext2Fsd (gratuito), mas não recomendo. É um driver pouco desenvolvido e nem suporta recursos básicos do EXT4 (na atual versão 0.69, falhará com qualquer volume criado por distribuições recentes). Existem drivers pagos (ex. Paragon extFS for Windows) que adicionam suporte à família EXT no Windows, cuja qualidade supostamente deve ser melhor, porém nunca testei, pois nunca comprei. Outra alternativa é usar Btrfs! O driver WinBtrfs (gratuito) tem desenvolvimento muito mais ativo e talvez valesse um teste.
  13. Com hardware de consumo não acho que haverá diferença entre XFS e EXT4. XFS tem vantagem quando o dispositivo de armazenamento consegue sustentar uma alta taxa de operações por segundo (imagine RAID com SSDs top de linha, por exemplo), daí pode mudar de figura. E o XFS suporta arquivos maiores que 16 TiB, algo que o EXT4 não suporta sem opções especiais de formatação. Enfim, teste e veja se faz alguma diferença...

Sobre o Clube do Hardware

No ar desde 1996, o Clube do Hardware é uma das maiores, mais antigas e mais respeitadas publicações sobre tecnologia do Brasil. Leia mais

Direitos autorais

Não permitimos a cópia ou reprodução do conteúdo do nosso site, fórum, newsletters e redes sociais, mesmo citando-se a fonte. Leia mais

×