我是一名普通的 Windows 用户，有时我会在 Linux 上开发一些东西，但当时为我提供了空间和机器。现在我自己使用 Microsoft Azure 和 Ubuntu 虚拟机，这个错误对我来说似乎很奇怪。为什么有很多挂载而不是像 /dev/ 这样的组合内存？我不能将它们完全合并吗？终端是否有一些命令可以将可用空间从拥有它的空间重新分配给没有它的空间。
我输入了df-i看看发生了什么，结果是：
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/root 3870720 396517 3474203 11% /
devtmpfs 2048512 464 2048048 1% /dev
tmpfs 2049470 63 2049407 1% /dev/shm
tmpfs 2049470 1051 2048419 1% /run
tmpfs 2049470 4 2049466 1% /run/lock
tmpfs 2049470 18 2049452 1% /sys/fs/cgroup
/dev/loop0 10833 10833 0 100% /snap/core18/2246
/dev/loop1 10836 10836 0 100% /snap/core18/2253
/dev/loop2 11736 11736 0 100% /snap/core20/1242
/dev/loop3 11776 11776 0 100% /snap/core20/1270
/dev/loop5 796 796 0 100% /snap/lxd/21835
/dev/sdb15 0 0 0 - /boot/efi
/dev/loop6 479 479 0 100% /snap/snapd/14295
/dev/loop7 479 479 0 100% /snap/snapd/14066
/dev/loop4 5777 5777 0 100% /snap/docker/1125
/dev/sda1 2097152 12 2097140 1% /mnt
tmpfs 2049470 37 2049433 1% /run/user/123
tmpfs 2049470 64 2049406 1% /run/user/1000
/dev/loop8 2268 2268 0 100% /snap/intellij-idea-community/337
/dev/loop9 40310 40310 0 100% /snap/postman/149
df -h：
Filesystem Size Used Avail Use% Mounted on
/dev/root 29G 27G 2.2G 93% /
devtmpfs 7.9G 0 7.9G 0% /dev
tmpfs 7.9G 83M 7.8G 2% /dev/shm
tmpfs 1.6G 1.5M 1.6G 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup
/dev/loop1 56M 56M 0 100% /snap/core18/2253
/dev/loop0 56M 56M 0 100% /snap/core18/2246
/dev/loop2 62M 62M 0 100% /snap/core20/1242
/dev/loop3 818M 818M 0 100% /snap/intellij-idea-community/337
/dev/sdb15 105M 5.2M 100M 5% /boot/efi
/dev/loop4 62M 62M 0 100% /snap/core20/1270
/dev/loop5 169M 169M 0 100% /snap/postman/149
/dev/loop7 68M 68M 0 100% /snap/lxd/21835
/dev/loop6 44M 44M 0 100% /snap/snapd/14295
/dev/loop8 117M 117M 0 100% /snap/docker/1125
/dev/loop9 43M 43M 0 100% /snap/snapd/14066
/dev/sda1 32G 49M 30G 1% /mnt
tmpfs 1.6G 20K 1.6G 1% /run/user/123
tmpfs 1.6G 28K 1.6G 1% /run/user/1000
答案1
您使用的是 Azure 虚拟机，因此您通常会获得他们为您提供的任何磁盘分区方案。
挂载/dev是一个devtmpfs文件系统，它是加载到 RAM 中的临时文件系统，主要由内核用来使设备文件可用。
挂载/run也是加载在 RAM 中的临时文件系统，主要由systemd需要临时文件空间的服务和其他服务使用。
安装/snap来自使用安装的软件包折断。这些利用loop设备并且通常不可写。当尝试写入任何这些位置时，您将收到某种“设备上没有空间”错误，这表示df -h为将这些安装显示为 100% 正在使用。
所有可用磁盘空间似乎都分配给两个设备：
/dev/root它报告总空间为 29G，已使用 27G，剩余 2.2G 可用并安装在/，也称为根文件系统。您的大部分数据看起来都在这里。该命令du -h --max-depth=1 /应显示磁盘空间的使用位置。
/dev/sda1其报告总空间为 32G，已使用 40M，剩余大约 30G 的可用空间，并安装在/mnt.您应该能够配置事物以使用该位置来存储数据。
要了解 Azure 为什么以这种方式处理磁盘的答案，您必须询问他们。如果您希望合并两个数据磁盘的空间并作为总空间为 60G 的单个安装提供，他们也许能够为您提供符合该标准的虚拟机。
答案2
正如您所看到的，所有这些“完整”文件系统都是/dev/loop设备。它们映射到文件，而不是磁盘。例如，您可以挂载 ISO 映像，并会看到相同的结果。这是摘录自man页：
循环设备是一种块设备，它不会将其数据块映射到硬盘或光盘驱动器等物理设备，而是映射到文件系统中常规文件的块或另一个块设备。
答案3
更高级一点：您拥有的每个“设备”都会有一个安装点。无法合并它们，并且您不希望您的可用空间在“设备”之间重新分配，这意味着文件最终会出现在与您放置它们的位置不同的“设备”上。
就您而言，没有真正的问题。所有完整的文件系统都是循环设备（即与文件对应的“设备”）并安装在 /snap 上，虽然我不知道 snap 是如何工作的，但它涉及虚拟文件系统并不令我感到惊讶。
答案4
@Jeredriq Demas：我在 Azure Linux VM 中面临类似的问题。你解决这个问题了吗？如果是这样，您可以发布解决方案吗