btrfs não mostra a unidade como ausente

Question

Estou experimentando o btrfs e notei um comportamento engraçado:

Eu tenho dois drives em uma configuração de raid 1.

sudo btrfs fi show
Label: none  uuid: 52b9c6f6-ce5c-4727-861e-e2fd012e475f
    Total devices 2 FS bytes used 251.16GiB
    devid    1 size 298.09GiB used 252.01GiB path /dev/sdi
    devid    2 size 298.09GiB used 252.01GiB path /dev/sdh

Como você pode ver, eles estão configurados como mdata=raid1, data=raid1 :

sudo btrfs fi df /btr/.fsroot/
Data, RAID1: total=251.00GiB, used=250.57GiB
System, RAID1: total=8.00MiB, used=64.00KiB
Metadata, RAID1: total=1.00GiB, used=597.47Mi

Agora, se eu falhar em /dev/sdh (por exemplo, puxe o cabo sata), tudo funciona como esperado,

sudo btrfs fi show
Label: none  uuid: 52b9c6f6-ce5c-4727-861e-e2fd012e475f
    Total devices 2 FS bytes used 251.16GiB
    devid    1 size 298.09GiB used 252.01GiB path /dev/sdi
    *** Some devices missing

o sistema de arquivos é desmontado. Mas o que me incomoda é o que acontece se eu falhar /dev/sdi :

Label: none  uuid: 52b9c6f6-ce5c-4727-861e-e2fd012e475f
    Total devices 2 FS bytes used 251.16GiB
    devid    1 size 298.09GiB used 252.01GiB path /dev/sdi
    devid    2 size 298.09GiB used 252.01GiB path /dev/sdh

Então, basicamente, a unidade com falha não é detectada. Isso não pode ser corrigido executando btrfs device scan . Então, em um ambiente de produção, como devo detectar, que meu ataque não existe mais?

    

Answer 1

Você limpou o sistema de arquivos BTRFS? Um scrub deve ler e verificar todas as cópias disponíveis. E é recomendado agendar um scrub, por exemplo, como cronjob mensal , então é assim que você seria notificado.

Para referência futura: Infelizmente, o BTRFS não parece ser capaz de detectar uma falha na transmissão "ao vivo", ou seja, enquanto o sistema de arquivos está montado (*) . Eu acho que eles não pensaram sobre sistemas de servidor que funcionam por meses ou até anos sem nunca serem desmontados. Vamos esperar que isso tenha sido corrigido agora (enquanto você está lendo isso) ...

*: Citando uma entrada da lista de discussão a partir de 09/2015:

The difference is that we have code to detect a device not being present at mount, we don't have code (yet) to detect it dropping on a mounted filesystem. Why having proper detection for a device disappearing does not appear to be a priority, I have no idea, but that is a separate issue from mount behavior.

link

O ZFS, por exemplo, perceberá que uma unidade que precisa ser acessada desapareceu e a marca como FAULTED. Para um servidor usando BTRFS, pode ser uma idéia ter uma verificação personalizada (trabalho cron) que envia um alerta se pelo menos uma das unidades na matriz RAID não estiver mais acessível ...

Montagens degradadas : Qualquer um que manualmente remover uma unidade para simular uma falha provavelmente pensará em montar o sistema de arquivos em modo degradado (por exemplo, usar "btrfs substitua "). A montagem no modo degraded (rw) pode ser perigosa, pode até levar à perda de dados se você não cuidar de ressincronizar seu sistema de arquivos depois (equilíbrio):

Just an FYI to be really careful about degraded rw mounts. There is no automatic resync to catch up the previously missing device with the device that was degraded,rw mounted. You have to scrub or balance, there's no optimization yet for Btrfs to effectively just "diff" between the devices' generations and get them all in sync quickly.

Much worse is if you don't scrub or balance, and then redo the test reversing the device to make missing. Now you have multiple devices that were rw,degraded mounted, and putting them back together again will corrupt the whole file system irreparably.

link