De acordo com a Intel, é importante que os blocos não sejam descartados ao criar um sistema de arquivos Linux em uma unidade de estado sólido. O documento afirma que o comportamento padrão (de mke2fsmarço de 2015) é não descartar blocos. No entanto, a página de manual atual mke2fsafirma que:
descartar:Tente descartar blocos no momento mkfs (descartar blocos inicialmente é útil em dispositivos de estado sólido e armazenamento esparso/thin-provisioned). Quando o dispositivo anuncia que o descarte também zera os dados (qualquer leitura subsequente após o descarte e antes da gravação retornar zero), marque todas as tabelas de inode ainda não zeradas como zeradas. Isso acelera significativamente a inicialização do sistema de arquivos.Isso é definido como padrão.
Quando formato um SSD manualmente, posso evitar o descarte de blocos durante a formatação adicionando-o -E nodiscardà mke2fslinha de comando, mas como os instaladores de distribuição são automáticos, não é possível fazer isso. Isso é algo para se preocupar?
Responder1
O documento vinculado parece servir a um propósito específico (desenvolvimento e benchmarking de driver NVME do kernel Linux) e não representa um conselho genérico para os usuários finais.
Ele afirma que o ext4 não descarta no momento do mkfs...
Sistemas de arquivos principais:
- ext4 – a opção estendida padrão é não descartar blocos no tempo de criação do sistema de arquivos, reter isso e não adicionar a opção estendida “descartar”, pois algumas informações lhe dirão para fazer.
- xfs – com mkfs.xfs, adicione a opção –K para não descartar blocos.
... e ainda assim acontece. É a primeira coisa que faz.
# mkfs.ext4 /dev/loop0
mke2fs 1.46.4 (18-Aug-2021)
Discarding device blocks: done
Creating filesystem [...]
Então, se você não quiser descartar todos os dados, você precisa evitá-los ativamente, para xfs usando mkfs.xfs -Kcomo sugerido, para ext4 com mkfs.ext4 -E nodiscard.
# mkfs.ext4 -E nodiscard /dev/loop0
mke2fs 1.46.4 (18-Aug-2021)
Creating filesystem [...]
Não sei se o comportamento padrão mudou. Pelo que posso dizer, sempre foi o padrão. Antes de -E descartar, as opções nodiscard surgissem, também havia -K para manter os dados (desativar o descarte padrão) sem nenhuma opção de contrapartida para ativar o descarte, caso estivesse desativado por padrão.
A página de manual uma vez afirmou que nodiscard era o padrão, mas não vejo isso refletido no código em nenhum lugar do histórico de commits, então talvez isso remeta a um erro de documentação.
mke2fs: Opção obsoleta -K, introduza descarte/nodiscard
(Na verdade, neste commit, ele alegou simultaneamente que descartar e nodiscard eram o padrão.)
Seria ótimo se nodiscard fosse o padrão e o fstrim não fosse possível até uma semana depois. O Linux é um pouco rápido para descartar seus dados. Formate o dispositivo errado e mesmo que você perceba seu erro imediatamente, já é tarde demais para fazer qualquer tipo de recuperação de dados.
Responder2
Antecipadamente: não estou realmente comprando.
Este documento é mais antigo e pode não ser mais preciso.
Além disso, pode estar claramente errado; historicamente tem havido muitas falhas de comunicação em torno disso, e as pessoas que escrevem guias não são necessariamente as mesmas que contribuem para o kernel Linux da mesma empresa. A situação é realmente complexa – a otimização para um SSD pode ser a pior coisa a fazer para outro, e os fabricantes de chipsets não encontraram uma maneira de comunicar as preferências de seus controladores.
No entanto, a funcionalidade de descarte do NVMe foi padronizada há muito tempo (a Intel esteve envolvida - na verdade, de forma dominante - nisso), e este é o uso pretendido, então eu ficaria um pouco surpreso se não fosse "bom".
Resumindo, usar o descarte fornece mais informações ao SSD - o que ele faz com isso depende do SSD. Portanto, trabalhar pior com mais informações que você poderia simplesmente ignorar: na verdade, é um problema de firmware do controlador SSD, não um problema de driver. Aposto que a Intel, muito interessada em ter bom suporte em datacenters Linux, já corrigiu esse problema há muito tempo.