事情开始于几周前：
- 当我尝试使用 vi 时，我得到了
"E297: Write error in swap file $ echo "test" > test生产-bash: echo: write error: No space left on device- 我的 bash 历史记录始终是空的
这不是我的配额，因为所有用户都是如此。
除此之外服务器似乎就好了……
我认为它可能是根/交换，但我不知道如何修复它。
以下是我认为可能有用的一些信息：
$ sudo df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/fileserver--00-root
224G 212G 0 100% /
none 995M 192K 995M 1% /dev
none 1000M 0 1000M 0% /dev/shm
none 1000M 14M 986M 2% /var/run
none 1000M 0 1000M 0% /var/lock
none 1000M 0 1000M 0% /lib/init/rw
/dev/sdb1 1.4T 1006G 356G 74% /cubo/d2p1
/dev/sdc1 459G 416G 39G 92% /cubo/d3p1
/dev/sda1 228M 17M 199M 8% /boot
192.168.1.7:/nfs/Backups
1.8T 1.2T 645G 65% /cubo/nfsMounts/ixBackup
还：
$ ll /dev/mapper/
total 0
crw-rw---- 1 root root 10, 59 2013-04-11 12:54 control
brw-rw---- 1 root disk 251, 0 2013-04-11 12:54 fileserver--00-root
brw-rw---- 1 root disk 251, 1 2013-04-11 12:54 fileserver--00-swap_1
附加信息
$ sudo dmsetup status
fileserver--00-swap_1: 0 11993088 linear
fileserver--00-root: 0 475701248 linear
和：
$ sudo dmsetup info
Name: fileserver--00-swap_1
State: ACTIVE
Read Ahead: 256
Tables present: LIVE
Open count: 1
Event number: 0
Major, minor: 251, 1
Number of targets: 1
UUID: LVM-z7USJS3uIlf3VVUPeDeE0TzljgezS31fcvrwZihBYEENf5Tkgsyb9xJHo3RNVXsT
Name: fileserver--00-root
State: ACTIVE
Read Ahead: 256
Tables present: LIVE
Open count: 1
Event number: 0
Major, minor: 251, 0
Number of targets: 1
UUID: LVM-z7USJS3uIlf3VVUPeDeE0TzljgezS31fdr57i4JAzZxlK6KeTOWDTm6bzUKK87J1
我的根文件夹大小：
$ cd /
$ sudo du -sh {bin,boot,cdrom,dev,etc,home,lib,lost+found,media,mnt,opt,proc,root,sbin,selinux,srv,sys,tmp,usr,var}
7.4M bin
17M boot
4.0K cdrom
192K dev
39M etc
1.1M home
154M lib
16K lost+found
4.0K media
4.0K mnt
4.0K opt
du: cannot access `proc/21251/task/21251/fd/4': No such file or directory
du: cannot access `proc/21251/task/21251/fdinfo/4': No such file or directory
du: cannot access `proc/21251/fd/4': No such file or directory
du: cannot access `proc/21251/fdinfo/4': No such file or directory
0 proc
48K root
7.5M sbin
4.0K selinux
4.0K srv
0 sys
16K tmp
542M usr
282M var
我的 fstab：
$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
/dev/mapper/fileserver--00-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=1724d880-01a4-481c-87e5-08328c3c8137 /boot ext2 defaults 0 2
/dev/mapper/fileserver--00-swap_1 none swap sw 0 0
/dev/sdb1 /cubo/d2p1 ext3 defaults 0 0
/dev/sdc1 /cubo/d3p1 ext4 defaults 0 0
/dev/sdd1 /cubo/d4p1 ext4 defaults,noauto 0 0
192.168.1.7:/nfs/Backups /cubo/nfsMounts/ixBackup nfs defaults 0 0
我该如何解决？
答案1
在聊天中调查问题后，确定了原因——根文件系统上的空间被隐藏在挂载点下面的文件占用（因此对来说是不可见的du）。
在 Linux 中，有两种方法可以访问挂载点下隐藏的文件和目录：
显而易见的方法 — 卸载挂载在目录上的文件系统，然后查看该目录中的内容。显然，在文件系统正在使用时，这是不可能做到的。
使用绑定挂载，可以使外部文件系统在树中的另一个目录中可访问，并且普通绑定挂载不是递归的 - 它们不会复制嵌套挂载，因此在旧位置被覆盖的目录在新位置可访问。这可以在正在运行的机器上执行，而不会中断使用文件系统的操作，因此这里将使用此方法。
对根文件系统执行此类绑定挂载的命令：
sudo mkdir /mnt/tmp_root
sudo mount --bind / /mnt/tmp_root
（在这种情况下/mnt/tmp_root可以使用，因为为根保留的空间并未 100% 被消耗。）
然后就可以找到隐藏在挂载点下面的大文件：
sudo du -x --max-depth=1 /mnt/tmp_root
sudo du -x --max-depth=1 /mnt/tmp_root/cubo
...
找到有问题的文件后，可以删除它们以释放空间。请注意，无法删除在同一文件系统的其他绑定挂载中用作挂载点的目录 — 例如，如果 NFS 文件系统挂载在/cubo/nfsMounts/ixBackup，则/mnt/tmp_root/cubo/nfsMounts/ixBackup无法删除（但可以删除其下的文件和目录）。
最后，一种防范未来出现此类问题的方法是加强对旨在用作挂载点的目录的权限，以便在出现阻止挂载的问题（例如，NFS 服务器没有响应）时，该目录无法访问，并且尝试访问它将以明显的方式失败：
sudo chown root:root /mnt/tmp_root/cubo/nfsMounts/ixBackup
sudo chmod 0600 /mnt/tmp_root/cubo/nfsMounts/ixBackup
（这将改变根文件系统上的目录的权限，但不会对可以挂载的文件系统造成任何影响/cubo/nfsMounts/ixBackup。）
最后的操作是不再需要绑定挂载后将其删除，并删除临时目录：
sudo umount /mnt/tmp_root
sudo rmdir /mnt/tmp_root
答案2
正如我在其他地方说过的，您的根分区已满。
该行224G 212G 0 100% /就是线索，您正在使用挂载在 / 上的 100% 的文件系统。