Durante a transferência de muitos arquivos de uma estação de trabalho Linux Redhat para um disco rígido externo FAT32
formatado ( WD 2 TB
formatado pelo utilitário de disco Mac), corri para o erro de não haver espaço suficiente no disco. Mas eu verifiquei que ainda havia ~700 GB
de espaço em disco, então estou supondo que fiquei sem espaço em disco por causa de nomes de arquivos longos (não tenho certeza?)? Como verificar isso?
Os detalhes do meu HDD externo são
/dev/sdc1 on /media/GUDDULINUX3 type vfat (rw,nosuid,nodev,relatime,uid=988,gid=2000,fmask=0022,dmask=0077,codepage=cp437,iocharset=ascii,s
Atualmente, existem cerca de ~545
diretórios com qualquer coisa entre ~7000
e ~11000
arquivos em cada diretório. Cada arquivo é um arquivo binário de tamanho (marcado com du -sh), ~32K
ou 96K
(aproximadamente metade de cada) e o nome é como XC6_9k.131_132.12.2012.210.s3
( 29
caracteres). O tamanho do arquivo parece OK porque eles devem ser arquivos binários com 8000
ou 24000
pontos flutuantes.
É possível que algo esteja errado? Infelizmente, não consigo verificar o espaço em disco exato consumido pelos diretórios, tentando du -sh
levar uma eternidade.
Editar 1 -
Eu usei o Mac Disk Utility para verificar o disco rígido externo e ele diz -
11361590 files, 1076797472 KiB free (33649921 clusters)
Editar 2 -
Seguindo as sugestões de Angelo, tentei df -h
e df -i
no disco rígido externo conectado ao meu laptop (mac). Parece que fiquei sem inodes livres em /Volumes/GUDDULINUX3
. Qualquer sugestão sobre o que fazer - ganharei inodes se eu tar
os arquivos pequenos em um arquivo tar
para cada diretório? Devo migrar para um disco% formatado em NTFS
?
avinash$ df -h
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
/dev/disk0s2 233Gi 216Gi 17Gi 93% 56587186 4482254 93% /
devfs 187Ki 187Ki 0Bi 100% 646 0 100% /dev
map -hosts 0Bi 0Bi 0Bi 100% 0 0 100% /net
map auto_home 0Bi 0Bi 0Bi 100% 0 0 100% /home
/dev/disk1s1 1.8Ti 836Gi 1.0Ti 45% 0 0 100% /Volumes/GUDDULINUX3
avinash$ df -i
Filesystem 512-blocks Used Available Capacity iused ifree %iused Mounted on
/dev/disk0s2 488555536 452185504 35858032 93% 56587186 4482254 93% /
devfs 373 373 0 100% 646 0 100% /dev
map -hosts 0 0 0 100% 0 0 100% /net
map auto_home 0 0 0 100% 0 0 100% /home
localhost:/rGEmV8JCfpffeQBEQFAlLe 488555536 488555536 0 100% 0 0 100% /Volumes/MobileBackups
/dev/disk1s1 3906009792 1752414720 2153595072 45% 0 0 100% /Volumes/GUDDULINUX3
Estes são resultados com o disco anexado à minha estação de trabalho Linux, ele não mostra as informações do inode.
seismo82% df -h /media/GUDDULINUX3/
Filesystem Size Used Avail Use% Mounted on
/dev/sdc1 1.9T 836G 1.1T 45% /media/GUDDULINUX3
seismo82% df -i /media/GUDDULINUX3/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdc1 0 0 0 - /media/GUDDULINUX3
Editar 3 -
Parece que inode
thing não funciona com FAT32
. Eu acho que o problema é que há um limite inferior em FAT32
em quantos arquivos podem estar lá em um diretório, menor que ~65k
dependendo do nome do arquivo. Primeiro, eu usei muitos arquivos existentes no ext HDD, o que deveria ter liberado muito inodes
(ou FAT32
equivalente). Mas ainda movendo o grande diretório (tem ~23k
arquivos) mostrou "nenhum espaço deixado no dispositivo" erro. Então, ao invés de mover arquivos individuais, fiz um tar do diretório e movi ele para o disco externo !!! Tentar desimpedi-lo no disco de ext me deu o erro novamente. Então, acho que encontrei um limite no número de arquivos no diretório. Veja o comentário do w3dk sobre isso
Máximo de arquivos por diretório
Eu verifiquei os diretórios que relataram erro ao mover. O limite parece 16383
arquivos para nomes de arquivos com 29
caracteres e 21843
arquivos para nomes de arquivos com 20
caracteres. Teoricamente, o limite é de ~65k
arquivos para arquivos com nomes em 8.3
format. Obrigado a todos que me ajudaram a diagnosticar o problema. Por enquanto, vou apenas aumentar o que tenho.