无法将大文件复制到ext2 USB记忆棒上[关闭]

我有一个8G USB记忆棒（我在linux Mint上），我正在尝试将5.4G文件复制到其中，但是

No space left on device

失败前复制文件的文件大小始终为3.6G

显示已安装的摇杆的输出。

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

因此，一个5.4G的文件似乎不会放在8G的USB记忆棒上。我以为ext2没有问题，而fat32的文件大小和USB记忆棒只是问题？更改格式会有所不同吗？

编辑：这是tunefs的驱动器报告

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
    

您的8GB记忆棒大约有7.5 GiB，即使有一些文件系统开销，也应该能够存储5.4GiB文件。

您用于tune2fs检查文件系统的状态和属性：

tune2fs -l /dev/<device>

默认情况下，root用户保留5％的空间。您的输出列出了97894个块，相当于大约385MiB，似乎是默认值。tune2fs如果不需要那么多保留空间，则可能需要使用来调整此值。但是，即使使用385MiB，该文件也应适合文件系统。

您的tune2fs输出显示文件系统不干净，并显示错误。因此，请fsck在文件系统上运行。这将修复错误，并可能在lost+found目录中放置一些文件。如果您不打算恢复数据，则可以删除它们。

这应该可以修复文件系统，并且复制文件将成功。

好的，我知道我是Windows用户，而不是Linux用户，但是前一段时间，当我尝试将文件复制到16Gig数据棒以与旧笔记本电脑进行传输时，我遇到了类似的问题。事实证明，大多数可移动设备的文件系统格式（ext2，fat32等）如果文件大小大于3.2Gig，则不支持复制文件，因为通常会为根目录和系统保留一些默认空间文件等...我通常会收到一个错误消息，告诉我驱动器已满（即使它完全是空的并且是新格式化的）。

经过研究后，我发现NTFS文件系统是将大型文件从系统传输到存储棒的最佳选择，因为它是唯一允许复制大于3.2的文件而没有任何问题的文件系统。

不知道这是否有帮助，但这始终是可能的解决方案。