无法写入磁盘,但磁盘未满


36

我正在使用Ubuntu 12.04,无法写入任何文件,即使是root用户,也不能执行任何其他需要写入的操作。不需要编写任何进程,因此它们都将失败。df说我有足够的空间:

Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       30G   14G   15G  48% /
udev            984M  4.0K  984M   1% /dev
tmpfs           399M  668K  399M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            997M     0  997M   0% /run/shm

我发现的所有关于“无法写入磁盘”的结果均与合法的完整磁盘有关。我什至不知道从哪里开始。这个问题今天早晨突然出现了。

PHP的最后一个日志条目是:

失败:设备上没有剩余空间(28)

Vim说:

无法打开(文件)进行写入

其他应用程序也会出现类似的错误。

可以肯定的是,删除〜1gb后,问题仍然存在。我也重新启动了。

df -i

Filesystem      Inodes   IUsed  IFree IUse% Mounted on
/dev/xvda1     1966080 1966080      0  100% /
udev            251890     378 251512    1% /dev
tmpfs           255153     296 254857    1% /run
none            255153       4 255149    1% /run/lock
none            255153       1 255152    1% /run/shm

14
请发布“ df -i”的输出。
EEAA

1
@EEAA已编辑。您是对的,df -i说100%。这是什么意思?为什么会有所不同?
felwithe 2015年

3
IIRC,单个目录中的太多文件将具有相似甚至不相同的症状。在文件系统之间,“太多”的含义会有所不同。
MSalters 2015年

Answers:


59

您没有inode。您的目录可能包含许多非常小的文件。


9
只是想补充一点,我什至不知道rm 失败。这是一种教育。
felwithe

2
@felwithe,我可以想象那find . -name sess\* -exec rm {} +会成功。
卡斯顿S

3
@felwithe其他人的建议。rm 可能工作得很好,但是shell将*glob 扩展为太多数据,并在调用 rm 之前将其驳倒。
CVn 2015年

8
@CarstenS:或者find . -name sess\* -delete我觉得更容易记住,并且通常更有效。
MSalters 2015年

2
@Kaslai的限制不是RAM,而是系统限制ARG_MAX。不幸的是,POSIX标准没有明确指定如何针对ARG_MAX测量命令行参数。某些实现没有限制,因此没有定义ARG_MAX,但这不是一个流行的选择,因为它会使太多程序无法编译。
James Youngman

7

显然,OP对他们的特定问题有答案。但是,出于完整性考虑,如果文件系统已经以只读方式重新挂载,则OP的症状也会出现。我使用Linux VM发生了这种情况,该Linux VM的存储位于群集磁盘系统上,并遇到罕见的间歇性故障。有时,这些故障会导致文件系统以只读方式重新挂载。最终可观察到的外部症状是,随着RAM的填充(带有无法刷新的磁盘写入),各种服务变得无响应。

当时,唯一的解决方法是重新引导系统(丢失所有未写入的日志)。尝试重新安装RW失败。(不幸的是,我不记得尝试这些重新安装时返回的错误消息。)

因此,...,不是OP的问题,但是到达此页面的其他人可能会从此信息中受益。


5
实际上没有;当文件系统被重新挂载为只读时,您会收到一条错误消息,指出该文件系统是只读的,而不是空间不足。
psusi 2015年

1
@psusi:我没有。我遇到各种错误,包括“文件系统已满”。如果过去两三年来这种情况发生了变化,那将是一件好事。
埃里克·塔

1
前几天,我试图将文件移动到Linux上的只读ZFS文件系统中。该错误相当清楚地表示为“只读文件系统”。
CVn 2015年

不; 过去30多年了。对只读fs的写操作将返回-EROFS;写入完整的fs将返回-ENOSPC。
psusi

4
@psusi:我看到您生活在幻想的世界中,程序员总是做正确的事情,而不是编写自己的错误消息。我似乎不住在那儿。
Eric Towers 2015年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.