redhat – mv:磁盘空间不足但可以cp

前端之家收集整理的这篇文章主要介绍了redhat – mv:磁盘空间不足但可以cp前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我们有一个奇怪的行为,我们不能再将文件移动到某个目录.我们明白了
  1. lstat("NewBatches/R910140805849312.dat",{st_mode=S_IFREG|0644,st_size=2850,...}) = 0
  2. lstat("Imported/R910140805849312.dat",0x7fff10424b90) = -1 ENOENT (No such file or directory)
  3. rename("NewBatches/R910140805849312.dat","Imported/R910140805849312.dat") = -1 ENOSPC (No space left on device)

但我们可以将文件复制到文件夹中.剩下大量的磁盘空间和inode.我们无法在该Imported子目录中移动该文件.所有其他人都在同一个EXT3文件系统中工作.

我有点不解

  1. # tune2fs -l /dev/mapper/vgdmscsp-lvmaspdoc
  2. tune2fs 1.39 (29-May-2006)
  3. Filesystem volume name: <none>
  4. Last mounted on: <not available>
  5. Filesystem UUID: b4215e24-2285-46de-8398-f41bc3174b8e
  6. Filesystem magic number: 0xEF53
  7. Filesystem revision #: 1 (dynamic)
  8. Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super
  9. Default mount options: (none)
  10. Filesystem state: clean
  11. Errors behavior: Continue
  12. Filesystem OS type: Linux
  13. Inode count: 33382400
  14. Block count: 52428800
  15. Reserved block count: 2619904
  16. Free blocks: 5432592
  17. Free inodes: 17432375
  18. First block: 1
  19. Block size: 1024
  20. Fragment size: 1024
  21. Reserved GDT blocks: 176
  22. Blocks per group: 8192
  23. Fragments per group: 8192
  24. Inodes per group: 5216
  25. Inode blocks per group: 652
  26. Filesystem created: Thu Oct 6 11:19:53 2011
  27. Last mount time: Sat Jul 12 09:26:56 2014
  28. Last write time: Tue Aug 5 00:04:31 2014
  29. Mount count: 40
  30. Maximum mount count: -1
  31. Last checked: Thu Oct 6 11:19:53 2011
  32. Check interval: 0 (<none>)
  33. Reserved blocks uid: 0 (user root)
  34. Reserved blocks gid: 0 (group root)
  35. First inode: 11
  36. Inode size: 128
  37. Journal inode: 8
  38. Default directory hash: tea
  39. Directory Hash Seed: b975b5a1-72ad-44a4-8c53-622f7ba71e25
  40. Journal backup: inode blocks

解决方法

您的空闲块数与保留计数相差不远.
  1. Block count: 52428800
  2. Reserved block count: 2619904
  3. Free blocks: 5432592

在创建时,ext3文件系统保留一定百分比的块供root用户使用,默认情况下为5%.这允许root拥有的进程在锁定用户空间的同时继续写入磁盘,而人们希望这是磁盘膨胀的来源.

我怀疑你作为一个没有特权的用户遇到了这个问题,而空闲块的数量低于保留计数.如果你以root身份进行干预,那么cp就会成功.如果您现在可以确认问题已经消失,并且当前空闲块数超过了保留计数,那么这是最可能的原因.

猜你在找的Linux相关文章