Não é possível resize2fs - combinação de flex_bg e! resize_inode

Question

Eu configurei recentemente meu primeiro software raid com o mdadm e depois de adicionar mais discos ao ataque, não consigo redimensionar o sistema de arquivos para o tamanho total do ataque. Eu criei um único sistema de arquivos (~ 16TB) em / dev / md0 via:

mkfs.ext4 -v -b 4096 -t huge -E stride=128,stripe-width=256 /dev/md0

Eu esperei dolorosamente por alguns dias enquanto todos os dados do antigo ataque eram copiados para o novo ataque; Mudei os discos e fiz o ataque e, finalmente, eu:

resize2fs -p /dev/md0

Que me informa que

resize2fs 1.42 (29-Nov-2011)
resize2fs: /dev/md0: The combination of flex_bg and !resize_inode features is not supported by resize2fs

Eu não entendo exatamente o que são essas duas características ou por que a combinação é problemática, então, contra meu bom senso, tentei adicionar resize_inode:

tune2fs -O +resize_inode /dev/md0

Mas eu fui abatido:

Setting filesystem feature 'resize_inode' not supported.

E eu não sou corajoso o suficiente para tentar remover o flex_bg, já que eu realmente não quero fazer nada que possa colocar meus dados em risco. Estou executando o Ubuntu 12.04 com o kernel 3.5.1:

Linux critter 3.5.1-030501-generic #201208091310 SMP Thu Aug 9 17:11:48 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Testei o resize2fs novamente com a v1.42.5 (a última versão disponível) sem sucesso. Então, para ser claro, minha pergunta é: como eu posso redimensionar esse sistema de arquivos ext4 para o tamanho do ataque (sem recriá-lo, de preferência)?

Editar: aqui estão algumas informações do sistema de arquivos que podem ser úteis.

tune2fs -l /dev/md0
tune2fs 1.42 (29-Nov-2011)
Filesystem volume name:   <none>
Last mounted on:          /media/Bigger
Filesystem UUID:          baecfa03-74c1-42ad-8e19-3b823f05f502
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              274700288
Block count:              4395202560
Reserved block count:     219760128
Free blocks:              247712956
Free inodes:              274636266
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        768
Flex block group size:    16
Filesystem created:       Fri Aug 17 02:54:50 2012
Last mount time:          Mon Aug 20 02:21:51 2012
Last write time:          Mon Aug 20 02:25:07 2012
Mount count:              3
Maximum mount count:      -1
Last checked:             Fri Aug 17 02:54:50 2012
Check interval:           0 (<none>)
Lifetime writes:          16 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      b357ba49-60b1-4c55-837f-a70c8285a8f5
Journal backup:           inode blocks

    

Answer 1

Isso pode ajudar você - link

Faça backups antes de fazer qualquer coisa, pois o que você está fazendo parece muito arriscado com o ext4.

Veja isto - link

WARNING: It is NOT recommended to resize the inodes using resize2fs with 
e2fsprogs 1.41.0 or later, as this is known to corrupt some filesystems. 

Até 16 TB parece factível com um sistema de arquivos ext4 de 64 bits, mas o estado das ferramentas parece estar em um fluxo. Esta é uma leitura muito boa - link

A menos que você tenha notícias de um desenvolvedor do sistema de arquivos ext4, você pode querer fazer esta pergunta nas listas de discussão ext4.

    

Answer 2

Chida - Eu encontrei anteriormente as mesmas URLs, mas sabia por experiência que o ext4 lidaria com mais de 16 TB com um kernel e ferramentas atualizados. Mas ainda não estava funcionando.

Finalmente, recebi uma resposta da lista de discussão linux-ext4 - a mkfs.ext4 comando que usei foi borked. Eu misturei -Te -T. Deveria ter lido:

mkfs.ext4 -v -b 4096 -t ext4 -T huge -E stride=128,stripe-width=256 /dev/md0

E então - foi-me dito - teria incluído resize_inode e funcionado como esperado.

Obrigado pela sua ajuda.

    

Answer 3

Eu sei que este é um antigo, mas apenas por alguém que leia isso no futuro ...

O flex_bg é (relativamente novo) um recurso que permite ao sistema de arquivos se dividir de maneira mais flexível nos "grupos de blocos". Tradicionalmente, ele é dividido em grupos de blocos com tamanhos iguais e predefinidos. A vantagem de flex_bg é que um grupo maior de blocos virtuais permitirá ter, por exemplo, uma maior tabela de inodos aglomerada - e então escrever lotes de arquivos pode acontecer mais rápido, já que não precisaria procurar espaço em outro grupo de blocos .

O resize_inode é um espaço pré-alocado para o caso em que você pode redimensionar o sistema de arquivos no futuro. É usado principalmente para tentar evitar a necessidade de mover a tabela de inodes fisicamente.

O resize_inode ocupa algum espaço e permite um redimensionamento mais suave e rápido de um sistema de arquivos, e flex_bg reduz as restrições de contagem de inode (contagem de arquivos / dir) e melhora o desempenho.

O mais triste é que o mkfs provavelmente não era potente o suficiente para poder alterar esses recursos em um sistema de arquivos no momento em que a questão foi postada, e ainda pode ter problemas para alguns recursos. Mas mudar esses não deve prejudicar seu sistema de arquivos, contanto que seja saudável. Então, sempre executa fsck -f /dev/SD... antes de tentar alterar esses recursos, e então você está pronto.