Impossible de copier un gros fichier sur une clé USB ext2 [fermé]

J'ai une clé USB 8G (je suis sous Linux Mint) et j'essaie de copier un fichier 5.4G dedans, mais

No space left on device

La taille du fichier copié avant l'échec est toujours de 3,6 G

Une sortie du manche monté montre ..

df -T
/dev/sdc1      ext2       7708584    622604   6694404   9% /media/moo/ba20d7ab-2c46-4f7a-9fb8-baa0ee71e9fe

df -h
/dev/sdc1       7.4G  608M  6.4G   9% /media/moo/ba20d7ab-2c46-4f7a-9fb8-baa0ee71e9fe

du -h --max-depth=1
88K ./.ssh

ls -h myfile 
-rw-r--r-- 1 moo moo 5.4G May 26 09:35 myfile

Donc, un fichier 5.4G ne semblera pas aller sur une clé USB 8G. Je pensais qu'il n'y avait pas de problèmes avec ext2, et c'était seulement des problèmes avec fat32 pour les tailles de fichiers et les clés USB? La modification du formatage ferait-elle une différence?

Edit: Voici un rapport de tunefs pour le lecteur

sudo tune2fs -l /dev/sdd1


Filesystem volume name:   
Last mounted on:          /media/moo/ba20d7ab-2c46-4f7a-9fb8-baa0ee71e9fe
Filesystem UUID:          ba20d7ab-2c46-4f7a-9fb8-baa0ee71e9fe
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         not clean with errors
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              489600
Block count:              1957884
Reserved block count:     97894
Free blocks:              970072
Free inodes:              489576
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      477
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8160
Inode blocks per group:   510
Filesystem created:       Mon Mar  2 13:00:18 2009
Last mount time:          Tue May 26 12:12:59 2015
Last write time:          Tue May 26 12:12:59 2015
Mount count:              102
Maximum mount count:      26
Last checked:             Mon Mar  2 13:00:18 2009
Check interval:           15552000 (6 months)
Next check after:         Sat Aug 29 14:00:18 2009
Lifetime writes:          12 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
Default directory hash:   half_md4
Directory Hash Seed:      249823e2-d3c4-4f17-947c-3500523479fd
FS Error count:           62
First error time:         Tue May 26 09:48:15 2015
First error function:     ext4_mb_generate_buddy
First error line #:       757
First error inode #:      0
First error block #:      0
Last error time:          Tue May 26 10:35:25 2015
Last error function:      ext4_mb_generate_buddy
Last error line #:        757
Last error inode #:       0
Last error block #:       0
    

Votre clé de 8 Go a environ 7,5 Gio et même avec une surcharge du système de fichiers, elle devrait pouvoir stocker le fichier 5,4 Gio.

Vous utilisez tune2fspour vérifier l'état et les propriétés du système de fichiers:

tune2fs -l /dev/<device>

Par défaut, 5% de l'espace est réservé à l'utilisateur root. Votre sortie répertorie 97894 blocs, ce qui correspond à environ 385 Mo et semble être la valeur par défaut. Vous voudrez peut-être ajuster cette valeur en utilisant tune2fssi vous n'avez pas besoin de beaucoup d'espace réservé. Néanmoins, même avec ces 385 Mo, le fichier devrait tenir sur le système de fichiers.

Votre tune2fssortie montre un système de fichiers impur avec des erreurs. Veuillez donc exécuter fscksur le système de fichiers. Cela corrigera les erreurs et placera éventuellement certains fichiers dans le lost+foundrépertoire. Vous pouvez les supprimer si vous n'avez pas l'intention de récupérer les données.

Cela devrait corriger le système de fichiers et la copie du fichier réussira.

Ok, je sais que je suis un utilisateur Windows, pas un utilisateur Linux, mais j'ai eu un problème similaire il y a quelque temps lorsque j'essayais de copier des fichiers sur une clé de données 16Gig, pour les transférer vers et depuis un ancien ordinateur portable. Il s'est avéré que la plupart des formats de système de fichiers pour les périphériques amovibles (ext2, fat32, etc.) ne prennent pas en charge la copie de fichiers si la taille du fichier est supérieure à 3,2 Go, car un espace par défaut est généralement réservé à la racine et au système. fichiers etc ... J'ai généralement une erreur me disant que le lecteur était plein (même s'il était totalement vide et fraîchement formaté).

Après avoir fait quelques recherches, j'ai découvert que le système de fichiers NTFS est le meilleur pour transférer des fichiers volumineux du système vers le stick, car c'est le seul système de fichiers qui permet de copier des fichiers plus grands que 3.2 sans aucun problème.

Je ne sais pas si cela vous sera utile, mais c'est toujours une solution possible.