Existe algum problema ao usar resize2fs com muita freqüência?

Question

Eu tenho uma partição que contém dados MySQL que estão em constante crescimento. Meu PV do LVM tem pouco espaço livre precioso e, portanto, descubro que estou frequentemente adicionando espaço adicional à minha partição /var usando lvextend e resize2fs em pequenos incrementos (250-500 MB por vez) para não dar muito espaço para /var e, em seguida, ser incapaz de alocar esses PEs para outras partições, caso eu precise de mais tarde.

Estou preocupado em atingir algum limite ou causar um problema chamando resize2fs com muita frequência para aumentar esse sistema de arquivos. Existe um limite para a frequência com que resize2fs pode ser usado para aumentar um sistema de arquivos Ext3? É melhor fazer um grande redimensionamento de Ext3 do que muitos pequenos? O redimensionamento usando resize2fs muitas vezes carrega um potencial para problemas ou perda de dados?

    

Answer 1

Além do desgaste dos HDDs, não consigo ver nenhuma razão pela qual isso seja perigoso. Eu nunca encontrei um parâmetro EXT3 / EXT4 que limitasse a quantidade de vezes que você pode fazer isso. Não há nenhum contador que eu tenha visto.

Ao analisar a saída de tune2fs , não vejo nada que possa ser alarmante, o que me levaria a acreditar que a execução de muitos redimensionamentos seria prejudicial ao sistema de arquivos ou ao dispositivo, além do desgaste.

Exemplo

$ sudo tune2fs -l /dev/mapper/vg_grinchy-lv_root
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          74e66905-d09a-XXXX-XXXX-XXXXXXXXXXXX
Filesystem magic number:  0x1234
Filesystem revision #:    1 (dynamic)
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
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              3276800
Block count:              13107200
Reserved block count:     655360
Free blocks:              5842058
Free inodes:              2651019
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1020
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sat Dec 18 19:05:48 2010
Last mount time:          Mon Dec  2 09:15:34 2013
Last write time:          Thu Nov 21 01:06:03 2013
Mount count:              4
Maximum mount count:      -1
Last checked:             Thu Nov 21 01:06:03 2013
Check interval:           0 (<none>)
Lifetime writes:          930 GB
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
First orphan inode:       1973835
Default directory hash:   half_md4
Directory Hash Seed:      74e66905-d09a-XXXX-XXXX-XXXXXXXXXXXX
Journal backup:           inode blocks

dumpe2fs

Você também pode cutucar os sistemas de arquivos EXT3 / EXT4 usando dumpe2fs , que essencialmente mostra as mesmas informações que tune2fs . A saída desse comando é demais para incluir aqui, principalmente porque inclui informações sobre os grupos de inodes dentro do sistema de arquivos. Mas quando eu passei pela saída, novamente eu não vi nenhuma menção de quaisquer contadores que eram inerentes aos sistemas de arquivos EXT3 / EXT4.