我们有一个奇怪的行为，我们不能移动文件到一个特定的目录了。 我们得到
lstat("NewBatches/R910140805849312.dat", {st_mode=S_IFREG|0644, st_size=2850, ...}) = 0 lstat("Imported/R910140805849312.dat", 0x7fff10424b90) = -1 ENOENT (No such file or directory) rename("NewBatches/R910140805849312.dat", "Imported/R910140805849312.dat") = -1 ENOSPC (No space left on device) 但是我们可以将文件复制到文件夹中。 有大量的磁盘空间，还有inode。 我们不能移动该文件，只是在该Imported子目录。 所有其他人在相同的EXT3文件系统中工作。
我有点困惑
# tune2fs -l /dev/mapper/vgdmscsp-lvmaspdoc tune2fs 1.39 (29-May-2006) Filesystem volume name: <none> Last mounted on: <not available> Filesystem UUID: b4215e24-2285-46de-8398-f41bc3174b8e Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 33382400 Block count: 52428800 Reserved block count: 2619904 Free blocks: 5432592 Free inodes: 17432375 First block: 1 Block size: 1024 Fragment size: 1024 Reserved GDT blocks: 176 Blocks per group: 8192 Fragments per group: 8192 Inodes per group: 5216 Inode blocks per group: 652 Filesystem created: Thu Oct 6 11:19:53 2011 Last mount time: Sat Jul 12 09:26:56 2014 Last write time: Tue Aug 5 00:04:31 2014 Mount count: 40 Maximum mount count: -1 Last checked: Thu Oct 6 11:19:53 2011 Check interval: 0 (<none>) Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode: 8 Default directory hash: tea Directory Hash Seed: b975b5a1-72ad-44a4-8c53-622f7ba71e25 Journal backup: inode blocks
您的空闲块数量与保留计数不是很远。
Block count: 52428800 Reserved block count: 2619904 Free blocks: 5432592
在创build时，ext3文件系统保留了根用户使用的块的百分比，默认为5％。 这允许根拥有的进程继续写入磁盘，同时locking用户空间，人们希望这是磁盘膨胀的来源。
我怀疑你是作为一个非特权用户遇到这个问题，而空闲块的数量低于保留计数。 如果您以root身份进行干预， cp将会成功。 如果您现在可以确认问题已经消失，并且空闲块的当前数量高于保留计数，那么这是最可能的原因。