Google Cloud Compute存储异常引发SSH连接失败问题咨询

嘿，你的这个问题确实有点让人困惑——SSH连GCP VM时提示没存储，但控制台能正常登进去，而且明明是20GB的磁盘却显示两倍大小。我来帮你一步步排查和解决：

一、先搞清楚磁盘显示翻倍的问题 #

这大概率是两种情况之一：

• 要么是磁盘被误扩容了但系统没识别：先去控制台的VM实例详情里，找到对应的持久磁盘，查看「磁盘大小」和「已使用空间」，确认是不是真的显示40GB。如果是的话，检查磁盘的操作历史，看看有没有误触发扩容操作。
• 要么是控制台显示的是磁盘总容量，但系统内只挂载了部分分区：通过控制台连接后，在终端里执行df -h，看看根分区（一般是/dev/sda1或/dev/nvme0n1p1）的实际容量，对比控制台的显示，就能区分是显示问题还是分区未扩容。

二、为什么SSH提示无存储但控制台能连？ #

这种情况几乎不会是磁盘整体满了，而是SSH服务依赖的特定目录空间不足，而控制台会话的运行环境不依赖这些目录：

• 先检查临时目录和系统日志目录：通过控制台执行df -h /tmp和df -h /var，这两个是SSH服务常用的临时存储和日志存储位置，看看是不是其中某个分区满了。
• 查看SSH服务的具体报错：执行journalctl -u sshd，找一找是不是/var/run或者/tmp空间不足，导致无法生成会话文件。
• 还有一种容易忽略的情况：磁盘inode耗尽。即使磁盘还有剩余空间，但inode（用来记录文件的元数据）用完了也会提示无存储。执行df -i，看根分区的IUse%是不是100%，如果是的话，就是这个问题。

三、具体解决步骤 #

1. 清理冗余文件释放空间 #

• 清理临时文件：sudo rm -rf /tmp/*（不用担心，/tmp的文件重启后会自动清除）
• 压缩或删除旧日志：sudo journalctl --vacuum-size=1G（把日志压缩到1G以内），或者手动删除/var/log下的旧日志文件（比如.old结尾的）

2. 修复inode耗尽问题 #

如果是inode满了，先找到占用大量inode的目录：

sudo find / -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n

这个命令会列出根目录下各文件夹的文件数量，从少到多排序。找到文件最多的目录（比如var或者tmp），进去清理冗余小文件（比如缓存、临时生成的小文件、旧的日志分片）。

3. 扩容系统分区（如果磁盘真的被扩容了） #

如果控制台显示磁盘是40GB，但df -h显示只有20GB，说明分区没跟上扩容：

• 先扩展分区：sudo growpart /dev/nvme0n1 1（这里的/dev/nvme0n1是你的磁盘设备名，根据实际情况调整）
• 再扩展文件系统：如果是ext系列文件系统，执行sudo resize2fs /dev/nvme0n1p1；如果是XFS文件系统，执行sudo xfs_growfs /

4. 重启SSH服务并测试 #

执行sudo systemctl restart sshd，然后尝试用SSH重新连接，应该就能解决问题了。

内容的提问来源于stack exchange，提问作者SujithaW