mv: fora do espaço em disco, mas pode cp

4

Temos um comportamento estranho de que não podemos mais mover arquivos para um determinado diretório. Nós recebemos

lstat("NewBatches/R910140805849312.dat", {st_mode=S_IFREG|0644, st_size=2850, ...}) = 0
lstat("Imported/R910140805849312.dat", 0x7fff10424b90) = -1 ENOENT (No such file or directory)
rename("NewBatches/R910140805849312.dat", "Imported/R910140805849312.dat") = -1 ENOSPC (No space left on device)

Mas podemos copiar o arquivo para a pasta. Há muito espaço em disco e também inodes. E não podemos mover o arquivo apenas nesse subdiretório Importado. Todos os outros trabalham dentro do mesmo sistema de arquivos EXT3.

Estou um pouco confuso

# tune2fs -l /dev/mapper/vgdmscsp-lvmaspdoc
tune2fs 1.39 (29-May-2006)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          b4215e24-2285-46de-8398-f41bc3174b8e
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal resize_inode dir_index filetype needs_recovery sparse_super
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              33382400
Block count:              52428800
Reserved block count:     2619904
Free blocks:              5432592
Free inodes:              17432375
First block:              1
Block size:               1024
Fragment size:            1024
Reserved GDT blocks:      176
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         5216
Inode blocks per group:   652
Filesystem created:       Thu Oct  6 11:19:53 2011
Last mount time:          Sat Jul 12 09:26:56 2014
Last write time:          Tue Aug  5 00:04:31 2014
Mount count:              40
Maximum mount count:      -1
Last checked:             Thu Oct  6 11:19:53 2011
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      b975b5a1-72ad-44a4-8c53-622f7ba71e25
Journal backup:           inode blocks
    
por Chris 05.08.2014 / 11:57

1 resposta

1

Sua contagem de blocos gratuitos não está muito longe da contagem reservada.

Block count:              52428800
Reserved block count:     2619904
Free blocks:              5432592

No momento da criação, o sistema de arquivos ext3 reserva uma porcentagem de blocos para uso pelo usuário root, que é de 5% por padrão. Isso permite que os processos de propriedade da raiz continuem gravando no disco enquanto bloqueia o espaço do usuário, o que se espera seja a origem do inchaço do disco.

Suspeito que você esteja enfrentando esse problema como um usuário sem privilégios enquanto o número de blocos livres estiver abaixo da contagem reservada. O cp teria sucesso se você estivesse intervindo como root. Se você puder confirmar que o problema desapareceu agora e o número atual de blocos livres estiver acima da contagem reservada, essa é a causa mais provável.

    
por 09.08.2014 / 19:50

Tags