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.