Maneira confiável de detectar ext2 ou ext3 ou ext4?

Question

Eu preciso detectar um tipo de sistema de arquivos de um programa C / C ++ usando o superbloco do sistema de arquivos. No entanto, não vejo muitas diferenças entre superblocos para ext2 e ext4. O campo s_rev_level é o mesmo (= 1), o s_minor_rev_level é o mesmo (= 0).

Eu poderia verificar alguns recursos de s_feature_compat (e outros campos de recursos) e tentar localizar recursos, que não são suportados pelo ext2. Mas - a pessoa, formatando uma partição, pode desativar alguns recursos de propósito. Portanto, esse método pode detectar o ext4, mas não pode distinguir entre o ext2 e o ext4 com recursos específicos do ext4 desativados.

Então, como fazer isso?

    

Answer 1

Depois de olhar o código para vários utilitários e o código do kernel por algum tempo, parece que @ sugerido por Hauke é verdadeiro - se um sistema de arquivos é ext2 / ext3 / ext4 é puramente definido pelas opções que são ativadas. / p>

Na página da Wikipedia em ext4 :

Backward compatibility

ext4 is backward compatible with ext3 and ext2, making it possible to mount ext3 and ext2 as ext4. This will slightly improve performance, because certain new features of ext4 can also be used with ext3 and ext2, such as the new block allocation algorithm.

ext3 is partially forward compatible with ext4. That is, ext4 can be mounted as ext3 (using "ext3" as the filesystem type when mounting). However, if the ext4 partition uses extents (a major new feature of ext4), then the ability to mount as ext3 is lost.

Como provavelmente já sabe, há compatibilidade semelhante entre ext2 e ext3 .

Depois de analisar o código qual blkid usa para distinguir diferentes ext filesystems , eu consegui transformar um sistema de arquivos ext4 em algo reconhecido como ext3 (e daí para ext2 ). Você deve conseguir repetir isso com:

truncate -s 100M testfs
mkfs.ext4 -O ^64bit,^extent,^flex_bg testfs <<<y
blkid testfs
tune2fs -O ^huge_file,^dir_nlink,^extra_isize,^mmp testfs
e2fsck testfs
tune2fs -O metadata_csum testfs
tune2fs -O ^metadata_csum testfs
blkid testfs
./e2fsprogs/misc/tune2fs -O ^has_journal testfs
blkid testfs

Primeira saída blkid é:

testfs: UUID="78f4475b-060a-445c-a5d2-0f45688cc954" SEC_TYPE="ext2" TYPE="ext4"

O segundo é:

testfs: UUID="78f4475b-060a-445c-a5d2-0f45688cc954" SEC_TYPE="ext2" TYPE="ext3"

E o final:

testfs: UUID="78f4475b-060a-445c-a5d2-0f45688cc954" TYPE="ext2"

Observe que precisei usar uma nova versão de e2fsprogs do que a disponível na minha distro para obter o sinalizador metadata_csum . O motivo da configuração e, em seguida, a limpeza foi porque não encontrei outra maneira de afetar o sinalizador EXT4_FEATURE_RO_COMPAT_GDT_CSUM subjacente. O sinalizador subjacente para metadata_csum ( EXT4_FEATURE_RO_COMPAT_METADATA_CSUM ) e EXT4_FEATURE_RO_COMPAT_GDT_CSUM é mutuamente exclusivo. A configuração metadata_csum desativa EXT4_FEATURE_RO_COMPAT_GDT_CSUM , mas a desativação metadata_csum não reativa o último.

Conclusões

Faltando um profundo conhecimento dos sistemas internos de arquivos, parece que:

1. A soma de verificação do diário deve ser uma característica definidora de um sistema de arquivos criado como ext4 que você não deve desabilitar e que o fato de ter conseguido isso é realmente um erro em e2fsprogs . Ou,

2. Todos os recursos ext4 sempre foram projetados para serem desativados e desativá-los torna o sistema de arquivos para todos os propósitos um propósito% a ext3 .

De qualquer forma, um alto nível de compatibilidade entre os sistemas de arquivos é claramente uma meta de design, compare isso com ReiserFS e Reiser4, onde Reiser4 é uma reformulação completa. O que realmente importa é se os recursos presentes são suportados pelo driver usado para montar o sistema. Como o artigo da Wikipedia observa, o driver ext4 pode ser usado com ext3 e ext2 (na verdade, há uma opção de kernel para sempre usar o driver ext4 e eliminar os outros). Desativar recursos significa apenas que os drivers anteriores não terão problemas com o sistema de arquivos e, portanto, não há motivos para impedi-los de montar o sistema de arquivos.

Recomendações

Para distinguir entre os diferentes sistemas de arquivos ext em um programa C, libblkid parece ser a melhor coisa a ser usada. É parte de util-linux e é isso que o comando mount usa para tentar determinar o tipo de sistema de arquivos. A documentação da API é aqui .

Se você tiver que fazer sua própria implementação da verificação, então testar os mesmos sinalizadores como libblkid parece ser o caminho certo a seguir. Embora notavelmente o arquivo vinculado não tenha nenhuma menção ao sinalizador EXT4_FEATURE_RO_COMPAT_METADATA_CSUM que parece ser testado na prática.

Se você realmente quisesse adivinhar todo o conteúdo, procurar por checksums de periódicos poderia ser uma maneira infalível de descobrir se um sistema de arquivos sem essas flags é (ou talvez era ) ext4 .

Atualizar

Na verdade, é um pouco mais fácil ir na direção oposta e promover um sistema de arquivos ext2 para ext4 :

truncate -s 100M test
mkfs.ext2 test
blkid test
tune2fs -O has_journal test
blkid test
tune2fs -O huge_file test
blkid test

Os três blkid de saídas:

test: UUID="59dce6f5-96ed-4307-9b39-6da2ff73cb04" TYPE="ext2"

test: UUID="59dce6f5-96ed-4307-9b39-6da2ff73cb04" SEC_TYPE="ext2" TYPE="ext3"

test: UUID="59dce6f5-96ed-4307-9b39-6da2ff73cb04" SEC_TYPE="ext2" TYPE="ext4"

O fato de os recursos ext3 / ext4 poderem ser tão facilmente ativados em um sistema de arquivos que começou como ext2 é provavelmente a melhor demonstração de que o tipo de sistema de arquivos é realmente definido pelos recursos.

    

Answer 2

Não é uma resposta direta, mas ao analisar a saída de tune2fs -l ... para cada tipo de sistema de arquivos, há as seguintes diferenças.

Recursos do sistema de arquivos

EXT2

Filesystem features: ext_attr resize_inode dir_index filetype sparse_super

EXT3

Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super

EXT4

Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

Parâmetros de registro no diário

EXT2

Não mostra nenhum parâmetro para registro no diário.

EXT3

Mostra isso:

Journal inode:            8

EXT4

Mostra isso:

Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       1967934