Devo usar o btrfs ou Ext4 para meu SSD?

15

Devo usar o btrfs (com opções descard, compress = lzo e space_cache) ou Ext4 (com opção de descarte) para o SSD para minha partição root do desktop Ubuntu amid64 do Ubuntu 11.10 (Oneiric) da minha máquina de escritório?

/ home será um HDD, portanto a confiabilidade do fs afeta o sistema operacional e não os dados.

    
por Graham 03.11.2011 / 10:37

4 respostas

12

De acordo com os testes de phoronix , sempre depende de muitos fatores. Em um caso Btrfs estará muito melhor que EXT4 ao ler arquivos grandes em um SSD. Da mesma forma, ao considerar o desempenho da transação em disco, Ext4 pode ter um desempenho melhor do que o posterior.

Você pode dar uma olhada nesses testes aqui , < href="http://www.phoronix.com/scan.php?page=article&item=btrfs_zfs_ssd&num=1"> aqui e aqui (AVISO: artigos longos).

Mas resumindo, o Btrfs agora não tem uma vantagem quantitativa de desempenho sobre o sistema de arquivos EXT4 , mesmo quando usado no modo SSD.

Então, você pode escolher mais de Ext4 por enquanto.

    
por Nikhil Ben Kuruvilla 04.11.2011 / 09:54
6

Para aqueles que tropeçam nesta questão em 2016 ... Use ext4. Eu tentei btrfs e a diferença é substancial. Em um período de 10 dias, os pedidos de veiculação para ext4 totalizaram 17.800 setores. Btrfs? 490.400 setores. O mesmo SSD, sistema de arquivos idêntico, partições diferentes. Basicamente, a mesma carga de trabalho.

Tanto o ext4 quanto o btrfs ficam "silenciosos" quando há zero atividade de gravação na unidade. Isso é bom.

O Ext4 gravará os dados modificados, além de alguma sobrecarga. Sobrecarga refere-se aos dados escritos. Uma gravação 4K (1 bloco) envia cerca de 50 a 80 blocos de sobrecarga no próximo commit. (O ext4 Journal está totalmente ativado)

Modifique um único bloco de 4K no btrfs e você vai empurrar entre 4000-5000 blocos de sobrecarga no próximo commit. O commit padrão é de 30 segundos, acredito. Eu usei 120.

Agora, depende de como você usa o SSD. Como root, normalmente há um fluxo constante e baixo de gravações acontecendo. Arquivos de log, arquivos de derivação ntp, reconstruções db man, atualizações de topologia opensm, etc, etc. Cada evento martelará uma unidade btrfs com outras gravações 4000-5000.

Os números de 10 dias acima são para o meu SSD "write limited". A maior parte desses 17.800 setores foi resultado de uma pequena atualização do sistema. Uma cópia do btrfs não sofreu. Meus escritores são, exatamente, drift ntp, topologia opensm e atualizações man db (todas as noites). Nada mais atinge esse disco, exceto coisas ativamente iniciadas, como upgrades de sistema, "vim / etc / whatever", etc.

Em todo SSDs vão sofrer muitas gravações, na verdade. Eu simplesmente não consigo ver o ponto em desperdiçá-los apenas porque a mídia está perseguindo coelhos e arco-íris. Se você quiser pagar esse preço por COW, vá em frente. Para "performance", não tanto. É um SSD e você provavelmente poderia colocar o pior "sistema de arquivos" conhecido pelo homem nele, e ainda obter algum nível de desempenho - apenas pela força bruta. Ext4 é, de longe, não o pior sistema de arquivos conhecido pelo homem.

Nenhuma verificação mensal de fs. Experimente o script abaixo. É 100% hackeado, não funciona para md mountpoints,

#! /bin/bash

dev = cat /proc/mounts | grep " " | awk '{print }'

x = basename $dev

vmnam = lsblk $dev -o MOUNTPOINT,PKNAME | grep "" | awk '{print }'

vmx = vmstat -d | grep $vmnam | awk '{print }'

lbax = smartctl -a $dev | grep LBA | awk '{print }'

tmpnam = mktemp XXX

echo "Dispositivo de rastreamento: $ dev, montado em $ 1 (vmstat on $ vmnam)"

tim = date +%s

timx = date +%s

enquanto verdadeiro

faça

vm='vmstat -d | grep "$vmnam" | awk '{print }''

lba='smartctl -a $dev | grep LBA | awk '{print }''

if [ "$vm" != "$vmx" ]

then

    tim='date +%s'

    dif='dc <<< "$vm $vmx - p"'

    lbad='dc <<< "$lba $lbax - p"'

    timd='dc <<< "$tim $timx - p"'

    echo 'date' " (sec=$timd) writes=$vm (dif=$dif) (lba=$lbad)"

    vmx="$vm"

    lbax="$lba"

    timx="$tim"

    find "" -mount -newer "$tmpnam" -print | grep -v "/tmp"

    touch "$tmpnam" 

fi

sleep 1 

concluído

Ele informará quantos blocos foram escritos, de acordo com a própria unidade, e exatamente quais arquivos foram atualizados. Precisa privs root. Veja por si mesmo. Eu corro o SSD no sistema de arquivos raiz e chamo o script stat.sh. Então ... "sudo ./stat.sh /"

    
por wkirk 29.09.2016 / 09:00
2

A última vez que testei e não ouvi nada diferente, mas em qualquer lugar, ext4 consome mídia em estado sólido. (thumbdrives, drives de estado sólido, etc.) Eu não recomendo usá-lo em tal dispositivo. Use ext3 em vez disso. Para a maioria dos casos em SSD, você não será capaz de dizer a diferença.

O BTRFS ainda não é bastante estável. No entanto, é estável o suficiente para aplicativos não críticos. É o que eu uso para criar unidades flash inicializáveis. Se você usar compress = zlib e ssd como opções de montagem, a compactação compensará as velocidades de gravação mais baixas da maioria das mídias de estado sólido e o ssd alterará o algoritmo de alocação para um que tenha um desempenho significativamente melhor nesses dispositivos e compensará qualquer baixo nivelamento de desgaste pelo hardware. A única área de desempenho que ainda é um problema é que as chamadas de sincronização são lentas. Isso não é um problema para uso geral, mas as chamadas do dpkg são sincronizadas após cada operação, portanto, instalar e atualizar o software pode ser lento. O BTRFS também oferece instantâneos e outros recursos avançados que são bastante úteis sob certas circunstâncias.

Se você decidir usar o BTRFS, use uma distro usando o kernel 3.2.0-2 ou posterior. 3.1.x é viável se necessário. Para kernels mais antigos, você precisará compilar os últimos módulos do BTRFS. Os embutidos são quase estáveis, mas a correção de erros não funciona nas versões mais antigas, o que pode deixar você em um riacho se algo der errado. As versões mais recentes têm fsck que pode realmente reparar as falhas mais comuns.

Uma última ressalva, eu ouvi relatos de que arquivos de swap em um sistema de arquivos BTRFS irão corrompê-lo. Esse problema pode ter sido corrigido, mas certifique-se de verificar cuidadosamente antes de implementar um.

Se você precisar de ajuda para configurar o BTRFS da maneira que desejar, me avise. Eu fiz alguns malucos que funcionam muito bem para coisas específicas.

    
por Perkins 15.05.2012 / 00:43
2

Eu não usaria o ext4 em uma unidade de estado sólido com base em evidências anedóticas e minha própria experiência que sugere que ext4 pode diminuir muito o tempo de vida de um SSD devido ao número de leituras e gravações associadas ao sistema de arquivos. Um artigo que li recentemente sugeriu que o ext4 não otimizado (responsável pelo tamanho da página, etc.) em um SSD pode reduzir a vida útil do disco pela metade. Após uma semana de solução de problemas, cheguei à conclusão de que meus próprios SSDs duraram apenas oito meses devido a esse problema. Se você usa um SSD, leia muito sobre como otimizar o sistema de arquivos com base em itens como tamanho de página flash, que pode ser diferente do tamanho de cilindro típico para o qual o sistema de arquivos está configurado.

    
por user75153 05.07.2012 / 09:10