☰

尝试将目录复制到服务器，但即使文件夹小于磁盘上的可用空间，服务器也会已满

tag-icon • tag-icon linux hard-drive raid scp
尝试将目录复制到服务器，但即使文件夹小于磁盘上的可用空间，服务器也会已满

问题

我正在尝试使用 将一个 112 GB 的目录复制到具有 214 GB 可用空间的服务器上的 RAID scp。但是，在复制一些文件后，我收到一条消息，告诉我磁盘已满，经过验证后，我发现磁盘确实已满。我不明白这是怎么可能的，我想了解并解决它。

细节

我使用的是 CentOS 7。在尝试复制目录之前，我刚刚在 raid 上安装了操作系统。这是df -h安装后的输出：

[user@localhost ~]$ df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root   50G  897M   50G   2% /
devtmpfs                 7,8G     0  7,8G   0% /dev
tmpfs                    7,8G     0  7,8G   0% /dev/shm
tmpfs                    7,8G  8,9M  7,8G   1% /run
tmpfs                    7,8G     0  7,8G   0% /sys/fs/cgroup
/dev/sda1               1014M  143M  872M  15% /boot
/dev/mapper/centos-home  214G   33M  214G   1% /home
tmpfs                    1,6G     0  1,6G   0% /run/user/1000

我正在尝试通过 scp 从运行 ubuntu 17.04 的笔记本电脑复制目录。这是目录的大小：

rick@rick-Inspiron-5448:~$ sudo du -hs /home/rick/
112G    /home/rick/

如您所见，服务器 RAID 上的可用空间略少于 214 GB，而我尝试复制的目录只有 112 GB。

我使用以下方法复制它

$ scp -r /home/rick/ [email protected]:/home/user/backup

它运行良好几个小时然后我反复收到以下输出：

scp: /home/user/backup/rick/<filename>: No space left on device

如果我输入的话df -h我就可以验证磁盘确实已满！

[user@localhost ~]$ df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root   50G  897M   50G   2% /
devtmpfs                 7,8G     0  7,8G   0% /dev
tmpfs                    7,8G     0  7,8G   0% /dev/shm
tmpfs                    7,8G  8,8M  7,8G   1% /run
tmpfs                    7,8G     0  7,8G   0% /sys/fs/cgroup
/dev/sda1               1014M  143M  872M  15% /boot
/dev/mapper/centos-home  214G  214G   20K 100% /home
tmpfs                    1,6G     0  1,6G   0% /run/user/1000

所以我从这个 ID 中了解到，我试图在有 214 GB 可用空间的磁盘上复制 112 GB，但不知何故磁盘在复制完成之前就被填满了。我知道我在这里遗漏了一些东西，但我看不出是什么。

这是我在服务器上配置的RAID信息：

RAID 信息

如果我可以提供任何其他详细信息来澄清我的情况，请告诉我。

更新

@AFH 评论表明问题可能与 i-node 有关，因此我运行

$ df -i
Filesystem                Inodes  IUsed    IFree IUse% Mounted on
/dev/mapper/centos-root 26214400  25686 26188714    1% /
devtmpfs                 2024232    474  2023758    1% /dev
tmpfs                    2026995      1  2026994    1% /dev/shm
tmpfs                    2026995    579  2026416    1% /run
tmpfs                    2026995     16  2026979    1% /sys/fs/cgroup
/dev/sda1                 524288    328   523960    1% /boot
/dev/mapper/centos-home   127080 126903      177  100% /home
tmpfs                    2026995      1  2026994    1% /run/user/1000

此外，输出fdisk

$ sudo fdisk -l
Disk /dev/sda: 292.3 GB, 292326211584 bytes, 570949632 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000b2997

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     2099199     1048576   83  Linux
/dev/sda2         2099200   570949631   284425216   8e  Linux LVM

因此，事实上，inode 已满。有什么建议可以解决此问题吗？

答案1

您的备份副本是否有符号链接？如果有，则使用 rsync 复制内容。带有 -r 选项的 scp 也会跟踪符号链接。

答案2

因此，事实上，inode 已满。有什么建议可以解决此问题吗？

如果不重新格式化文件系统，就无法增加 inode 的数量。

目前您有大约 120 GB 的空间无法使用，因为您没有相应的 inode。

您可以尝试以下方法：

  • 将 LVM 分区（危险）上的文件系统大小减少约 110 GB，例如resize2fs，
  • 缩小 LVM 分区以完全适合文件系统（同样很危险），
  • 在可用空间中创建一个新分区
  • 现在可以挂载新的分区。

例如，您可以查看是否有几个目录可以容纳 110 GB 的空间（/home/user/downloads 等），将该目录的内容移动到新分区，然后将该分区挂载到旧目录中。现在，您有可用的空闲空间（和 inode）等于移动文件的大小。

整个操作需要仔细规划，我强烈建议进行完整备份。

答案3

经过一段时间，我找到了解决问题的方法。问题是，当我复制scp文件时，wine目标文件夹的大小与源文件夹的大小完全不同。

我不确定这是否与wine复制占用了比应有的更多的 i 节点有关，或者 wine 是否在其文件夹内被递归复制，但当我检查时df -h，wine文件夹在源处有 1.5GB，在服务器上有 101GB，这就是的命运scp。

我清除了服务器上的磁盘并使用进行了备份rsync，并且scp工作正常。

感谢所有提供帮助的人，这是一个艰难的周末。

相关内容