Os discos podem e corrompem silenciosamente os dados. Veja link para um exemplo de pesquisa sobre isso.
Sou novo no BTRFS e estou tentando entender por que o BTRFS usa o CRC32c, enquanto o HDD já tem ECC de integridade de dados no nível do setor. É porque os BTRFS não transmitem mídia para ter proteção de integridade de dados? Obrigado.
Os discos podem e corrompem silenciosamente os dados. Veja link para um exemplo de pesquisa sobre isso.
Eu apenas não compro tais argumentos que os discos regularmente têm erros não declarados e o colocam no FUD. Sim, se você lançar dados aleatórios suficientes no código de detecção de erros, às vezes informará que os dados estão corretos quando não estão. Aqui está a coisa: a unidade não está tentando ler dados aleatórios. Ele está lendo dados que foram gravados e lidos corretamente de volta. Isso então passa por um código de correção de erros que pode consertar um número de bits errantes. Para obter um erro não declarado, você precisa obter um número muito maior de erros brutos para sobrecarregar o ECC e, em seguida, eles precisam ser organizados apenas para que a saída do ECC seja organizada < em> apenas à direita que engana o EDC em pensar que é bom. As probabilidades são muito mais altas que pelo menos o EDC irá notar o erro e reportá-lo como um erro incorrigível. Com que frequência isso acontece? Basicamente nunca, a menos que uma unidade esteja se aproximando de falha ou tenha uma perda repentina de energia durante uma gravação. Então, se um erro incorrigível quase nunca acontece, e um erro não reportado é um milhão de vezes menos provável, o que isso lhe diz?
Por outro lado, se você está armazenando uma cópia duplicada de seus dados de qualquer forma, provavelmente é bom ter alguma maneira de dizer qual deles está correto no caso altamente improvável de que uma cópia se torne silenciosamente corrupta. Além disso, o crc é útil para detectar blocos que contenham cópias duplicadas dos mesmos dados, para que possam ser desduplicados, que é outro recurso de design do btrfs.
btrfs é um sistema de arquivos de próxima geração - abrange muitos dos mesmos propósitos que os modelos de camadas anteriores manipulados entre eles. btrfs também é uma pilha extensivamente grande - a faq recomenda que seja gravada em um disco não particionado * [s] * e que todos os particionamentos, cotas, compactação, geração de imagens, distribuição, cópia na gravação, deduplicação e provavelmente 10 outras coisas que estou esquecendo são tratadas apenas como qualidades do sistema de arquivos. Pode fazer tudo isso e muito mais.
btrfs são dinâmicas - elas podem ser adicionadas e excluídas de um sistema ativo sem problemas. Isso funciona porque btrfs fragmenta os grupos de blocos de armazenamento apenas quando eles desejam - e eles podem estar em qualquer dispositivo específico em sua matriz atual quando isso ocorre. O FAQ tem algumas coisas a dizer sobre isso - particularmente onde ele fala sobre a falta de confiabilidade das estimativas de espaço livre:
For example, if you have one subvolume as "single", and one as RAID-1, then the first subvolume will consume raw storage at the rate of one byte for each byte of data written. The second subvolume will take two bytes of raw data for each byte of data written. So, if we have 30GiB of raw space available, we could store 30GiB of data on the first subvolume, or 15GiB of data on the second, and there is no way of knowing which it will be until the user writes that data.
So, in general, it is impossible to give an accurate estimate of the amount of free space on any btrfs filesystem. Yes, this sucks. If you have a really good idea for how to make it simple for users to understand how much space they've got left, please do let us know, but also please be aware that the finest minds in btrfs development have been thinking about this problem for at least a couple of years, and we haven't found a simple solution yet.
A leitura da seção relevante oferecerá exemplos mais específicos, mas deixa muito claro que btrfs de dispositivos pode ser variável em número, epehemeral em persistência, bloqueada e distribuída separadamente ou em conjunto e ... bem, continua . Outra citação do FAQ:
Device management is a complex subject, and there are many different opinions about the best way to do it. Internally, the Btrfs code separates out components that deal with device management and maintains its own layers for them. The vast majority of filesystem metadata has no idea there are multiple devices involved.
Diz isso sobre o RAID:
btrfs supports RAID-0, RAID-1, and RAID-10. As of Linux 3.9, btrfs also supports RAID-5 and RAID-6 although that code is still experimental.
btrfs combines all the devices into a storage pool first, and then duplicates the chunks as file data is created. RAID-1 is defined currently as "2 copies of all the data on different devices". This differs from MD-RAID and dmraid, in that those make exactly n copies for n devices. In a btrfs RAID-1 on three 1 TB devices we get 1.5 TB of usable data. Because each block is only copied to 2 devices, writing a given block only requires exactly 2 devices to be written to; reading can be made from only one.
Recuperação de dados:
The advantage in btrfs-raid 5/6 is that unlike MD-RAID, btrfs knows what blocks are actually used by data/metadata, and can use that information in a rebuild/recovery situation to only sync/rebuild the actually used blocks on a re-added or replacement device, skipping blocks that were entirely unused/empty in the first place.
MD-RAID can't do that, because it tries to be a filesystem agnostic layer that doesn't know nor care what blocks on the layers above it were actually used or empty. For it to try to track that would be a layering violation and would seriously complicate the code and/or limit usage to only those filesystems or other layers above that it supported/understood/could-properly-track.
É claro que btrfs foi projetado desde o início até as camadas transcendentes . Para isso, deve manter uma árvore de soma de verificação, reconstruível e esperançosamente pelo menos um tanto redundante, que compreende todos os seus dispositivos atualmente incorporados. btrfs é, em muitos aspectos, um banco de dados de arquivos, bem como um sistema de arquivos. Ele não depende de dispositivos subjacentes para ecc porque, em grande parte, não considera que são dispositivos subjacentes. Você pode pensar nisso como um disco kudzu, talvez.
Em qualquer caso, é precisamente o checksum constante e o gerenciamento de metadados que permitem que btrfs faça muitas das coisas interessantes que ele faz, e faça isso sem muita consideração pelo hardware subjacente.
Sim, não confia no dispositivo para relatar erros ou armazenar os dados corretos em primeiro lugar. Se isso é realmente necessário é outra questão inteiramente. Não é algo que alguém se preocupa, geralmente, e as coisas simplesmente funcionam.
Se você tiver um disco que não relate erros, você terá um grande problema; não são apenas os sistemas de arquivos que dependem de tais relatórios de erro, mas também outros componentes, como controladores RAID, etc .; armazenamento não confiável coloca seus dados inteiros em risco, não apenas alguns bits.
Independentemente de seu sistema de arquivos fazer checksum, você deve sempre executar seus próprios testes no armazenamento; como testes automáticos SMART, ou no caso de RAID, verifique se há incompatibilidades nos dados de paridade ( /sys/block/mdX/md/mismatch_cnt = 0 após executar uma verificação sync_action).
Tags data-recovery btrfs