Vraisemblablement, vous verrez une sorte d'erreur "Pas d'espace disponible sur l'appareil":
# truncate -s 100M foobar.img
# mkfs.ext4 foobar.img
Creating filesystem with 102400 1k blocks and 25688 inodes
---> number of inodes determined at mkfs time ^^^^^
# mount -o loop foobar.img loop/
# touch loop/{1..25688}
touch: cannot touch 'loop/25678': No space left on device
touch: cannot touch 'loop/25679': No space left on device
touch: cannot touch 'loop/25680': No space left on device
Et en pratique, vous atteignez cette limite bien avant "4 milliards de fichiers". Vérifiez vos systèmes de fichiers avec les deux df -h et df -i pour savoir combien d'espace il reste.
# df -h loop/
Filesystem Size Used Avail Use% Mounted on
/dev/loop0 93M 2.1M 84M 3% /dev/shm/loop
# df -i loop/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/loop0 25688 25688 0 100% /dev/shm/loop
Dans cet exemple, si vos fichiers n'ont pas une taille moyenne de 4K, vous manquez d'espace inode beaucoup plus tôt que d'espace de stockage. Il est possible de spécifier un autre ratio (mke2fs -N number-of-inodes ou -i bytes-per-inode ou -T usage-type tel que défini dans /etc/mke2fs.conf ).
Une fois la limite atteinte, les tentatives ultérieures de création de fichiers échoueront avec ENOSPC , indiquant que le système de fichiers cible n'a pas de place pour de nouveaux fichiers.
Dans le scénario que vous décrivez, cela entraînera généralement l'abandon du transfert une fois la limite atteinte.